-
Notifications
You must be signed in to change notification settings - Fork 564
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
HTTP2 and http:// URIs on the "open" internet #314
Comments
Just playing devil's advocate, but a simple option is to say nothing. |
Yep, that's definitely one option. |
Using https instead of http doesn't just change the bits on the wire but has also a number of other important side effects (at least) in browsers. For example referrers may not be sent anymore, information in form fields isn't stored anymore for autocompletion etc. etc. I think it would be very beneficial to still keep this distinction of sensitivity/confidentiality. Whether traffic to http URIs is then (optimistically) encrypted or not, doesn't really matter to the average end user. The different UX on the hand does. |
Since MITM https:// proxies exist and are widely deployed, https:// is no safer than http:// for open internet usage. I think we need to revisit the existing HTTP/1.1 Upgrade header, which specifically talks about supporting future major versions of HTTP. Aside from addressing how HTTP/2.0 proxies would work/interoperate, it would seem to deal with the perceived reliability issues as well. |
Gents, Good to see the discussion, but it needs to take place on the list not here. Thanks, |
Discussed in Zurich; the WG agreed that we will allow HTTP2 to be used with HTTP URIs, with or without TLS, without constraints from us. |
A number of browser implementers have stated an intent to only implement HTTP/2 over TLS for traffic over the "open" internet.
They can achieve that today by only implementing HTTP/2 for https:// URIs, requiring site that wish to use the new protocol to redirect http:// URIs, possibly using HSTS to "pin" that upgrade.
As such, we do not necessarily need to specify this with requirements (e.g., with a MUST or MUST NOT); those sites that want to use the new protocol with these browsers will implement the pattern above.
However, to promote interoperability, we might want to give guiding language or even requirements to frame this. This issue is specifically for collecting proposals for such text.
The text was updated successfully, but these errors were encountered: