Re: Rechartering HTTPbis

On 27/01/2012 11:32 a.m., Willy Tarreau wrote:
> On Fri, Jan 27, 2012 at 11:03:19AM +1300, Adrien de Croy wrote:
>>>> I think it may possibly solve more problems than it would create to
>>>> simply use a different port for "http 2.0", and not try to achieve
>>>> backward compatibility / interoperability with 1.x on the same port.
>>> The same subject was discussed to great extents on hybi, and the big
>>> problem with using a new port and/or with incompatible upgrades is
>>> that you enter a chicken-and-egg problem. Browsers won't use the
>>> new protocol by default until there is enough adoption on the server
>>> side, and server siders won't waste their time and money deploying and
>>> maintaining a second parallel infrastructure for years just for the few
>>> geeks around who click the "use fancy http" box. The current status of
>>> HTTP pipelining and TCP ECN describes the process very well.
>> yeah, that's a fairly compelling argument against any sort of change.
>>
>> we need to overcome this if we want to move forwards.  Forever is a long
>> time, and to be stuck with HTTP as it is....
> Well, HTTP/1.0 is still much present too... 15 years after RFC2068.
>
>> Maybe there is some other compelling issue we can overcome with http,
>> which would provide the incentive to deploy 2.0 and we can slip all the
>> other changes in on the coat-tails of the answer to that.
>>
>> Although Google with SPDY have proven that new protocols can be deployed.
> I'm not sure there are *that* many deployments, except enthousiasts. Home
> users generally do not experience much filtering. However in the enterprise
> world you can literally wait for several years before your new port is open
> with all the filtering components installed etc...
>
>> But at the moment, if we were to make all the proposed changes to HTTP,
>> it would be like trying to change TCP to have 32bit port numbers.
> If we make them by brute force, yes. If we make them as an upgrade, it
> might work. PHK suggested that the first request should be 1.1 and that
> upon this connection we'd upgrade to 2.0. I too find that this is the
> safest path. The client does not need to speak to other ports, and
> knows after one round trip whether the server supports the upgrade or
> not. This is quite cheap and compatible with existing infrastructure,
> allowing both versions to coexist.

I wouldn't rely on support for Upgrade.  Since there's basically no 
deployed users of it (I've never seen an upgrade header in 17 years) I 
would expect it to break on many intermediaries, and so the test for 
HTTP/2.0 support wouldn't be reliable.

Therefore it's likely everyone will choose instead CONNECT to tunnel, 
it's reliable.

In fact due to the number of sites moving to https, the incidence of 
traffic bypassing everything with a tunnel through the proxy is becoming 
a bigger and bigger problem.

Hence my previous statement about deprecating CONNECT, and making sure a 
corporate proxy has access to the payload and http protocol.

It would be trivially simple for a client to issue GET https://etc 
instead of tunnelling... in fact it would simplify client code a fair 
bit.... if the client could rely on the proxy supporting it.

So... maybe we need an OPTIONS command specifically for proxies, to 
enable a proxy to advertise supported protocol features.

POP3 has it, SMTP has it, maybe it's HTTPs turn now :)

>
>> At least with IP4 ->  IP6 there is a compulsion, due to address space.
>> There's no such compulsion with HTTP, it works well enough for the
>> people who use it.
>>
>> It's depressing but it's something we all face.  Unless we can get
>> commitment from all major server and client vendors to implement and
>> roll out changes, we won't get very far.  So maybe we should start there?
>>
>> At least if we moved to a different port, intermediaries (e.g. those
>> intercepting TCP/80) would be none-the-wiser and wouldn't try to mess
>> with the traffic/protocol.  That would limit the scope of required
>> supporting agent types to just clients and servers for a start.
> Not always, it's often the opposite. I've seen mobile phone operator platforms
> where only 80 and 443 are proxied to the outside, the rest simply being
> blocked. And in the enterprise world, you generally do not even route to
> the outside, you have to pass through a number of proxies.
>
> Still, HTTP Upgrade header makes a lot of sense for this.
>
> Regards,
> Willy
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

Received on Thursday, 26 January 2012 22:46:28 UTC