Re^2: HSTS policy breaks cpan utility on Windows

acronym explained ++

Surely encryption is out of scope for HTTP. That's the reason for https. The user should declare which protocol they want to use, and the provider which are available, where required.

Comment on Re^2: HSTS policy breaks cpan utility on Windows

Replies are listed 'Best First'.
Re^3: HSTS policy breaks cpan utility on Windows by marto (Cardinal) on Nov 21, 2019 at 15:01 UTC
rt://130819. The end user may not be aware of the underlying issues, a https default makes sense, forcing those who understand the issue to make the change where appropriate.	[reply]
Re^4: HSTS policy breaks cpan utility on Windows by Don Coyote (Hermit) on Nov 21, 2019 at 15:22 UTC
Default to the secure option is fair.	[reply]
Re^5: HSTS policy breaks cpan utility on Windows by syphilis (Archbishop) on Nov 22, 2019 at 01:34 UTC
Default to the secure option is fair But the case here is that the "secure option" is being enforced. If I want to download www.cpan.org/authors/01mailrc.txt.gz, I'm forced to do it securely. A fresh build of perl (from source) has no capability (AFAICS) to perform such a secure download. Therefore the cpan utility is initially reliant on some external utility that is capable of a secure download - and there's no guarantee that such an "external utility" exists. If no such external utility is available to cpan, then cpan is unusable on a fresh build of perl, no matter how you configure it. That's a rather annoying situation to be in - especially if, as Anonymous Monk asserts elsewhere in this thread, it's a situation created by the cpan.org webserver. Cheers, Rob	[reply]
Re^6: HSTS policy breaks cpan utility on Windows by cavac (Prior) on Nov 22, 2019 at 08:14 UTC
Re^7: HSTS policy breaks cpan utility on Windows by syphilis (Archbishop) on Nov 22, 2019 at 09:12 UTC
Some notes below your chosen depth have not been shown here