Clarification for HEAD/GET behaviour for blobs across repos

[DenverJ]

Can I please get clarification on the expected behaviour for HEAD/GET requests for different repositories in a registry. IE given that /v2/repo-a/testimg/blobs/sha256:abc123 exists.

What is the expected behaviour/response for:
HEAD /v2/repo-b/testimg/blobs/sha256:abc123
and
GET /v2/repo-b/testimg/blobs/sha256:abc123

We are using an OCI conformant registry that is currently returning 200 for the HEAD and 404 for the GET.

[tianon]

Personally, I'd consider such a server non-compliant to the HTTP spec (let alone the OCI): https://www.rfc-editor.org/rfc/rfc9110.html#name-head 😬

It's not as clear in https://github.com/opencontainers/distribution-spec/blob/v1.1.1/spec.md#checking-if-content-exists-in-the-registry as it probably should be, but individual blobs are considered in the API to be per-repository, so the most compliant answer is that a client needs to assume that it needs to explicitly push (or blob-mount) a digest into a given repository before it can assume it's there. However, the way to determine that is via HEAD, which is again repository specific (because access control/storage of the blob in the registry might be), so this is definitely a buggy registry without question.

[rchincha]

Also mention which registry has this behavior?

And no DELETEs have happened between HEAD and GET - garbage collection, deletes, retention policies, etc