Crane

Do we still need to support the Docker v1 protocol? Docker v2 content won't do this with the current implementation.

If you are really sure that v2 content doesn't suffer from this issue, then I think we can probably drop this issue, because support of v1 will be dropped in late July this year.

There are some important factors to consider for the general feature being requested, which is for crane to make sure a resource really is available before redirecting to it. I see the issue was closed while I was writing this, but I'll add it anyway for posterity.

In a case where the redirect source requires authentication, we would need to teach crane how to authenticate and give it credentials. For example, consider content that requires an entitlement certificate for access. Crane's HEAD request would need to use a valid entitlement cert. Someone would have to make sure the entitlement cert gets replaced when it expires. Or for any other kind of auth, credentials will change at some point, and someone needs to handle that. This also increases the complexity of deploying crane, because now the deployer would have to inject and maintain secrets.

Crane currently does not require outbound network access of any kind. This feature would not only add a dependency on outbound access (which to be fair often isn't a big deal), but would require that crane has access to the same network resources as the client it is responding to. For most deployments that is probably not a big deal, but it is a valuable point of flexibility that would be lost.

Related to needing access to the same network resources, consider that thanks to things like DNS and network routing, crane's view of https://foo.bar may be very different from the client's.

Making requests before responding with redirects would increase crane's response time by a huge factor. That may be acceptable, but it's a consideration. For a high-traffic deployment, doubling the response time might mean doubling the amount of infrastructure running crane.

Making requests also adds a big new opportunity for failure. Right now, crane is basically bullet-proof. It's very simple. Everything it needs to generate a response is in-memory. Depending on remote requests brings up many new edge cases and failure scenarios that need to be handled. For example, how long should it wait for a response? Consider would would happen if one server for one repo stopped responding or became very slow. On a busy crane deployment, you could quickly end up with all of your available request handlers waiting on a response or timeout from that one server, and no handlers available to respond to client requests for other resources. Guarding against that would be difficult.

Depending on what scenario you are concerned about, a better option may be to use a real monitoring tool to monitor resource availability, and disable/enable repositories in crane as appropriate. That could be an interesting point of integration to explore, and it is definitely a good way to guard against the timeout issue above.