Re: A proposal

Hi PHK,

So, this is effectively a proposal of how to upgrade plaintext HTTP/1 to HTTP/2. It has some interesting properties, and similar things have been mentioned in the past. Personally, I think a separate port for unencrypted HTTP/2 is interesting.

However, the question at hand is whether and when HTTP/2 will be *used* for HTTP URLs, not the specifics of the upgrade mechanism. We've had plenty of discussion about that, and I encourage you to familiarise yourself with where we've been on that (much of your proposal overlaps with or is compatible with previous discussion on the topic).

To be clear -- the current draft says NOTHING to constrain http:// URLs in the draft; this means that the status quo is that implementations select what conditions they implement HTTP/2 under. We have at least two browsers that have clearly indicated they will only do so for https:// URLs, and significant support for that position from others.

I can see two possible paths forward:

* We can continue to say nothing, meaning that at least some implementations will only implement HTTP/2 for https:// URIs, and interop will be determined by the market (read: chaotic). If we keep on spinning our wheels, this is likely where we'll end up; we can't let this issue dominate the rest of our work.

* We can compromise and agree upon when and where HTTP/2 can be used for http:// URLs (e.g., for .local and RFC1918 addresses, and/or when alternate mechanisms for important aspects of security are layered in, whether that's opportunistic encryption or something else). This is where I think more discussion will help.

If anyone can suggest another realistic approach, we're listening.

Again, the relevant issue:
  https://github.com/http2/http2-spec/issues/314

Cheers,



On 18/11/2013, at 6:58 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> 1. HTTP/2 on port 100 is always plaintext, which makes life easy
>   for network people and is conceptually simple for everybody
>   to understand.  It also does not need any RTT before HTTP/2
>   performance benefits kick in.
> 
> 2. Encrypted HTTP/2 will go over 443 (if SSL/TLS is used, otherwise
>   I suspect that will need a new port too ?)  This makes life
>   easy and is conceptually easy to understand too.
> 
> 3. Servers or intermediaries which can do HTTP/2 (port 100 and/or
>   443) can indicate this two ways:
> 
>   a) By sending a header in only the *first* HTTP/1 response on
>      any connection.
> 
>      This new header must be listed in "Connection:" since protocols
>      supported is by nature a hop-by-hop property.
> 
>      (For further study:  Make this a general purpose header which
>      can also indicate HTTPS, SCTP or other protols supported ?)
> 
>   b) In DNS records. (For futher study:  How ?)
> 
>   Servers should do both. Intermediaries can only do a).
> 
> 4. URIs in HTML documents do not change.
> 
> 	"http:" means "no privacy needed"
> 	"https:" means "privacy required"
> 
>   The user-agent gets to resolve that into HTTP/1 and HTTP/2 (or
>   any other protocols), according to policy, preference and custom,
>   based on server provided information, possibly cached.
> 
> 5. Upgrading a HTTP/1 connection on port 80 to HTTP/2 will not
>   be supported, the risk of reducing web relibility is too high and
>   it would add RTT costs before HTTP/2 performance benefits kick in.
> 
> 6. Upgrading a HTTP/1 connection on port 443 to HTTP/2 is desired
>   only if HTTP/2 cannot be a negotiated option during the TLS -
>   handshake.  I don't know the answer to this one, it may for
>   further study ?

--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 18 November 2013 03:12:49 UTC