Re: Rechartering HTTPbis

On 27/01/2012 10:01 a.m., Willy Tarreau wrote:
> On Fri, Jan 27, 2012 at 09:46:43AM +1300, Adrien de Croy wrote:
>> one other thing, I think we are losing site of context here.
>>
>> We're discussing possible features for a new protocol which is not
>> necessarily syntactically compatible with HTTP/1.x
> Indeed.
>
>> This means that every piece of deployed HTTP infrastructure would need
>> to be upgraded if it wishes to support the new protocol.
>>
>> So raising roadblocks for general protocol features on the basis of very
>> limited existing 1.x implementations serves no useful purpose.
>>
>> In that light, I'll throw something else out there.
>>
>> 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....

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.

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.

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.

>
> Due to the size of the current web, the only upgrade path seems to be
> by starting compatible and possibly upgrading, but in any case the
> failure must be immediate and clean, otherwise painful failures will
> result in the new version being disabled by default and enabled by
> noone.

>> There - I said it :)
> So did I :-)
>
> 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:04:00 UTC