Re: #385: HTTP2 Upgrade / Negotiation

------ Original Message ------
From: "Yoav Nir" <ynir@checkpoint.com>
To: "Patrick McManus" <pmcmanus@mozilla.com>
Cc: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>;"Mark 
Nottingham" <mnot@mnot.net>;"Willy Tarreau" <w@1wt.eu>;"Amos Jeffries" 
<squid3@treenet.co.nz>;"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 26/10/2012 2:21:46 a.m.
Subject: Re: #385: HTTP2 Upgrade / Negotiation
>On Oct 25, 2012, at 3:01 PM, Patrick McManus wrote:
>
>
>>
>>I know this has been said before by the Chrome team, but I too am starting to see websocket bugs pile up due to transparent proxies that don't speak upgrade and explicit proxies that don't let you tunnel to port 80 as configured.
>>
>
>
>Transparent proxies should learn about Upgrade: and either support websockets/http2 or remove the header. Hopefully they will have done this by the time HTTP/2.0 over port 80 is actually deployed.
>
>
>>
>>(bluecoat and MS ISA/TMG are the most common I hear about). ws:// hasn't been very successful in those environments but wss:// has been. Good thing that in the websockets world there aren't a lot of legacy urls to worry about - not true for http :(
>>
>>For http2, I don't think it is enough to just fail fast to http/1 when for most cases we could get those users speaking HTTP/2 over tls on 443. A mechanism like Alternate-Protocol accomplishes that and I think that is a more important property than upgrading in band (which is admittedly nice!).
>>
>
>
>So rather than go to HTTP/1.1 you'd prefer going to TLS with an anonymous ciphersuite?  I don't think that would help much, as the transparent proxies that also MitM SSL are getting ever more popular.
>
>
>>
>>As for caching successful upgrades or successful A-P's they pretty much have the same set of tradeoffs.
>>
>
>
>Yes, but I don't think it's all that bad. Browsers and operating systems have some feeling of location, which changes when any of your IP addresses change, or your routing table changes, or the configuration of the proxy or DNS servers changes. Browsers notice these things so that they can quickly re-establish connections, re-query the DNS, and reload pages that had some failure.  If you have this event also invalidate the cache, so that you go through the Upgrade handshake again, you should usually not have a case where a proxy has suddenly got in your path and won't let you use HTTP/2 over TCP port 80 any more.
>

On this note, I think it would be really useful if there could be some 
machine-readable way to query a proxy for HTTP-related capabilities.  
If that were part of 2.0, then failure to respond appropriately to such 
a query would in itself be an indication of lack of support for 2.0.

The client could do this test whenever it became aware of using a new 
proxy, e.g. before anyone types a URI or clicks a shortcut.  So by the 
time the first user request is made, the client should know all it 
needs to know about the proxy.  We should at least be able to solve 
that part of the problem.

Adrien


>
>
>Yoav
>
>
>
>

Received on Thursday, 25 October 2012 21:34:29 UTC