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

Support for non-TLS HTTP #1763

Closed
djettah opened this issue Dec 13, 2022 · 6 comments
Closed

Support for non-TLS HTTP #1763

djettah opened this issue Dec 13, 2022 · 6 comments
Labels
kind/feature A request for, or a PR adding, new functionality

Comments

@djettah
Copy link

djettah commented Dec 13, 2022

Currently using HTTP registries indroduces severe timeouts as HTTP works only as a fallback from HTTPS:

Thanks for your report. This behavior is currently hard-coded; the “try also non-TLS HTTP” and “do not require a trusted certificate and an authenticated connection when using TLS HTTPS” options are both configured using the same *tls-verify=false, with no way to choose only one of the two.
(from containers/skopeo#1519)

It would be beneficial to have an option disabling TLS.

@mtrmac
Copy link
Collaborator

mtrmac commented Dec 13, 2022

Thanks for your report. Does the option of using explicit :80 not make a difference?

Either way, transferring to c/image, where that new option would need to be implemented.

@mtrmac mtrmac added the kind/feature A request for, or a PR adding, new functionality label Dec 13, 2022
@mtrmac mtrmac transferred this issue from containers/skopeo Dec 13, 2022
@djettah
Copy link
Author

djettah commented Dec 13, 2022

Thanks for your report. Does the option of using explicit :80 not make a difference?

No, the registry is already on non-standard port.

@mtrmac
Copy link
Collaborator

mtrmac commented Dec 13, 2022

So, to confirm, the delay is in that the registry accepts the connection, but somehow takes a long time to reject the TLS negotiation as an invalid HTTP request?

@djettah
Copy link
Author

djettah commented Dec 14, 2022

Yes, it waits 30s until a timeout fires:

...
DEBU[0000] GET https://artifactory-sage-1.ds.sage-next.local:9002/v2/
DEBU[0030] Ping https://artifactory-sage-1.ds.sage-next.local:9002/v2/ err Get "https://artifactory-sage-1.ds.sage-next.local:9002/v2/": dial tcp 10.232.41.14:9002: i/o timeout (&url.Error{Op:"Get", URL:"https://artifactory-sage-1.ds.sage-next.local:9002/v2/", Err:(*net.OpError)(0x400049a190)})
DEBU[0030] GET http://artifactory-sage-1.ds.sage-next.local:9002/v2/

Tweaking such timeouts could be also an option.

@djettah
Copy link
Author

djettah commented Dec 14, 2022

It turned out I had only set http_proxy without https_proxy that's why timeout happened. Solved my problem but an option would still be useful.

@mtrmac
Copy link
Collaborator

mtrmac commented Sep 20, 2024

This is also tracked as #2088, and that one includes a bit more discussion; please follow there.

@mtrmac mtrmac closed this as not planned Won't fix, can't repro, duplicate, stale Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A request for, or a PR adding, new functionality
Projects
None yet
Development

No branches or pull requests

2 participants