You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Google HTTP client gives null content for HEAD requests. Docker registry can return useful content for HEAD responses. In BlobChecker, this content can contain useful registry error codes to parse.
Proposed solution: Do a HEAD, then a GET
The text was updated successfully, but these errors were encountered:
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.
From GoogleContainerTools/minikube-build-tools-for-java#116
The Google HTTP client gives null content for HEAD requests. Docker registry can return useful content for HEAD responses. In
BlobChecker
, this content can contain useful registry error codes to parse.Proposed solution: Do a HEAD, then a GET
The text was updated successfully, but these errors were encountered: