- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Sun, 17 Nov 2013 12:53:03 -0600
- To: James M Snell <jasnell@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
As a web page author, how do I choose which scheme, http:// or http2://, to use for a link? Do I need to detect the browser version the page is rendered on? On Sun, Nov 17, 2013 at 12:08 PM, James M Snell <jasnell@gmail.com> wrote: > The volume on the other threads on the security subject is causing far too > much noise. I have a proposal that offers a compromise approach. I posted > about this partially in one of the threads but I'm afraid it got lost in the > noise. Others have touched on the same basic idea: > > 1. By default, assign plain text http/2 to a new port. > 2. Document that plaintext http/2 can be sent over port 80 but document the > various possible issues with reliability. > 3. Strongly recommend that http/2 be sent over TLS instead of plaintext. > 4. Establish a new http2 URL protocol prefix for plaintext http2 over the > new default port > > This does several things. > > A. It makes plaintext http/2 possible but significantly harder. Some. Would > argue that makes plaintext http/2 "undeployable"... The same people who have > argued that have also argued that plaintext http/2 should not be used at > all. Therefore, those people really do not lose anything by following this > approach. > > B. It makes http/2 over TLS the default for the public internet since that's > the only option that would be broadly deployable on today's infrastructure. > > C. It makes it less likely that we would have to deal with the upgrade dance > on port 80. Which is a good thing. Http:// URLs would always mean http/1.x. > Http2://example:80 would mean http/2 over port 80. > > D. Developers would be forced to make a conscious choice to use plaintext > http/2 over an established default port. There's zero ambiguity. > > The folks who are arguing for TLS only really lose nothing with this > approach. It still, over course, does nothing about the mitm issues on port > 443, but its a start. > > - James >
Received on Sunday, 17 November 2013 18:53:30 UTC