Crane

@ipanova will take look and we will triage it next time.

right now Crane works the way registry works if a docker client talks to it( through docker engine).

Registry bases its logic on the headers sent from the docker client.

so if looking at the case you've mentioned:

Right now if there is (for example) a manifest list at sha256:0123456..., a GET request for /v2/{name}/manifests/sha256:012346... but without any Accept: header redirects the client to /pulp/docker/.../manifests/1/sha256:012346..., not to the .../list/... location.

Registry looks at the headers. there are none there, that implies that it is an older docker client and registry will try to convert it to schema1 but the problem is that the manifest is pulled by digest and not tag this would lead to ( taking form docker docs)

When the manifest is pulled by _digest_ with Docker Engine 1.9 and older, the same rewriting process will not happen in the registry. If this were to happen the digest would no longer match the hash of the manifest and would violate the constraints of CAS.

For this reason if a manifest is pulled by digest from a registry 2.3 with Docker Engine 1.9 and older, and the manifest was pushed with Docker Engine 1.10, a security check will cause the Engine to receive a manifest it cannot use and the pull will fail.

https://docs.docker.com/registry/compatibility/

In Crane case it would redirect to schema1 and it would lead to 404
if we would 100% mimic the registry behavior, the final result will any lead to a manifest pull which would eventually fail.

I don't think we covered the cases of direct API calls, we would always rely of the fact that there is a 'docker pull', which is smarter and sets the headers accordingly.

OK, that's totally fair.

based on the discussion with Tim, we can close it.