W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: #385: HTTP2 Upgrade / Negotiation

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 26 Oct 2012 14:28:09 +1300
Message-ID: <5089E729.9050801@treenet.co.nz>
To: ietf-http-wg@w3.org
On 26/10/2012 10:34 a.m., Adrien W. de Croy wrote:
>
> ------ 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.

You mean "OPTIONS * HTTP/..." ?

Amos
Received on Friday, 26 October 2012 01:28:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 26 October 2012 01:28:47 GMT