Work around Google HTTP client giving null content for HEAD requests.

[coollog]

Work around Google HTTP client giving null content for HEAD requests.

[chanseokoh]

I'm starting to question if the proposed do-HEAD-then-GET is needed for practical purposes (although I haven't looked into the Docker registry protocol.) If HEAD does not return 2xx for the given digest, it can never mean the registry has the blob in question. I think the only gain with the second GET is that we can verify if the server is really saying the given digest is absent or the server is not well-behaving. But even when the server is not well-behaving, we are checking the code 404, so we will halt and surface other non-404 and 2xx responses immediately. Not to mention 404 seems enough to over-approximate the absence of the blob. Even if 404 was due to a server malfunctioning, the subsequent pushBlob() will surface a problem.

[chanseokoh]

However, this might matter if we are going to have a complete registry client library. I don't know.

[chanseokoh]

As I said earlier, I think we are fine to not implement the proposed do-HEAD-then-GET in practice.

However, we have some code around this including a TODO, so we need to clean them up.

jib/jib-core/src/main/java/com/google/cloud/tools/jib/registry/BlobChecker.java

Lines 69 to 82 in 37e37b6

	if (responseException.getContent() == null) {
	// TODO: The Google HTTP client gives null content for HEAD requests. Make the content never
	// be null, even for HEAD requests.
	return Optional.empty();
	}
	// Find a BLOB_UNKNOWN error response code.
	ErrorCodes errorCode = ErrorResponseUtil.getErrorCode(responseException);
	if (errorCode == ErrorCodes.BLOB_UNKNOWN) {
	return Optional.empty();
	}
	// BLOB_UNKNOWN was not found as a error response code.
	throw responseException;