RE: Call for Proposals re: #314 HTTP2 and http:// URIs on the "open" internet

I've been following this very interesting discussion as an observer.
We all agree that since HTTP/2.0 message formats are not backwards compatible with HTTP/1.x
the proxies processing HTTP/2.0 requests will cause problems and break end-to-end HTTP/2.0.
In most networks this is a temporary situation though.
Eventually the proxies in the HTTP request processing path will get software updates and they will get support for HTTP/2.0.
Once that happens end2end HTTP/2.0 in plaintext would be possible.

I wonder if some detection mechanism could be added to HTTP/2.0 protocol to detect HTTP/1.x proxies between client and server.
If HTTP/1.x proxy is detected HTTP communication would not be eligible for upgrade to HTTP/2.0.
If no proxies or only HTTP/2.0 proxies are detected the connection can be upgraded to HTTP/2.0.
HTTP/1 detection should always be done first before switching to HTTP/2.

Alternatively a client would attempt HTTP/2 connection first and if it fails
it would roll back to HTTP/1.1 connection.

Also some HTTP/2.0 over HTTP/1.x proxy traversal mechanism could be designed.
Possibly using HTTP/1.x CONNECT.
This would work like this:
* run 1.x proxy detection
* if 1.1 proxy detected issue HTTP/1.1 CONNECT
* run HTTP/2.0 over HTTP/1.1 CONNECT session

Thanks,
Piotr

-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu] 
Sent: Wednesday, November 20, 2013 10:12 AM
To: Michael Sweet
Cc: Poul-Henning Kamp; Adrien de Croy; James M Snell; Mark Nottingham; Bjoern Hoehrmann; HTTP Working Group
Subject: Re: Call for Proposals re: #314 HTTP2 and http:// URIs on the "open" internet

On Wed, Nov 20, 2013 at 09:58:56AM -0500, Michael Sweet wrote:
> Willy,
> 
> On Nov 20, 2013, at 4:03 AM, Willy Tarreau <w@1wt.eu> wrote:
> > ...
> > Note that I'm regularly reading here that Upgrade always wastes a 
> > round trip, which is wrong. First, when the browser knows that the 
> > destination supports Upgrade, it can send the payload immediately 
> > after the headers. Second, 101 is an interim response meaning that 
> > the complete response is supposed to follow. So if you send 
> > something like "OPTIONS * HTTP/1.1\r\nUpgrade: HTTP/2.0\r\n..." it 
> > will need a round trip because we won't get any data with 101. But 
> > if you send "GET / HTTP/1.1\r\nUpgrade: 2.0\r\n", the server must 
> > reply to this request and provide the contents. The response can 
> > very well look exactly like a server push in practice, in that from 
> > a 2.0 point of view, the server sends first.
> 
> It is my understanding from prior comments that the GET-with-upgrade 
> method does not work with some/many proxies (I?m still waiting to hear 
> which ones?),

All those who didn't understand from 2616/2817 how it was supposed to be used. Haproxy in versions prior to 1.3 was one of those. I've seen a number of nginx, apache and squid versions not support it either. Packet-based load balancers are even more affected (eg: Alteon used to be, never tried versions after 22.x). That said, many of them tend to behave the same way and simply ignore the Upgrade header without removing it. Those which rebuild a new request cause no trouble, they just don't support the upgrade (apache/nginx/squid were in this category and did not hang). Old haproxy versions would simply let the 101 pass and would either let the rest pass through or close the connection after the 101 message. Packet based products are really the worst ones.

> so doing a GET that advertises the capability (without the Connection:
> upgrade header) and following up with an OPTIONS request when the 
> server?s response also includes Upgrade: HTTP/2.0 might be the best we 
> can reliably do (but still a lot better than opening dozens of 
> parallel connections to get the page?s linked resources?)

In my opinion, advertising the capability will not provide anything since the problematic devices are the non-compliant ones which will ignore your advertisement. Upgrade easily allows both ends to agree on what they both support, they just don't know that there's some crap in the middle.

Willy

Received on Wednesday, 20 November 2013 16:36:30 UTC