2 ms·
TLS is in fact a valid protocol to use in an Upgrade header: HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade So you c
by notpushkin 2y ago
TLS is in fact a valid protocol to use in an Upgrade header:
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
So you can use 426 Upgrade Required here, and I'd argue it's the most correct code to use in such a case. npm doesn't send the Upgrade header though, so that's a mistake.
https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml https://www.iana.org/assignments/http-upgrade-tokens/http-up...
https://www.rfc-editor.org/rfc/rfc2817.html#section-4.2 https://www.rfc-editor.org/rfc/rfc2817.html#section-4.2
- chrismorgan 2y agoThat’s something different: that’s for upgrading to TLS within the same connection. As in, approximately http://example.com/ http://example.com/ → https://example.com:80/ https://example.com:80/ (but without the URL’s scheme actually being allowed to change), whereas https://example.com/ https://example.com/ is https://example.com:443/ https://example.com:443/. I was only a child when RFC 2817 was published, but I’ve never heard of any software that supported it, other than the Internet Printing Protocol which can use it for ipp: URLs, kinda like SMTP has STARTTLS. As for the motivations of RFC 2817, they’re long obsolete: encryption should no longer be optional on these sorts of things so that the parallel secure port problem is gone (not sure when this became actual IETF policy, but I’m going to guess towards ten years ago), and the virtual hosting problem is solved by SNI (supported by everything that matters for well over a decade).