Re: Rechartering HTTPbis

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.

> 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

Received on Thursday, 26 January 2012 22:33:37 UTC