Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2/client: friction around insecure registries and the is_v2_supported method #89

Closed
steveej opened this issue Feb 1, 2019 · 1 comment · Fixed by #91
Closed

v2/client: friction around insecure registries and the is_v2_supported method #89

steveej opened this issue Feb 1, 2019 · 1 comment · Fixed by #91
Labels

Comments

@steveej
Copy link
Contributor

steveej commented Feb 1, 2019

IMHO the result of the is_v2_supported() method isn't correct as it is.
In case of querying a v2-supported registry via plain http, the 301 status code (MOVED) will cause the method to return false to indicate that v2 is not supported here.
The correct behavior would be look at the new URL and if the scheme changed to https, instead of returning false, throw an error which reports that the requested scheme is not supported.

I'll go ahead and call this a bug, but I'd like to know the original motivation behind this in case I'm missing something.

@lucab
Copy link
Member

lucab commented Feb 4, 2019

The original motivation is that specs do not contemplate redirection there: https://docs.docker.com/registry/spec/api/#api-version-check

However I do agree that for a client to be helpful it should be able to handle redirections on most of the paths. Also, all common registries seems to have a redirection in place for HTTP to HTTPS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants