Re: Rechartering HTTPbis

On Fri, Jan 27, 2012 at 11:45:56AM +1300, Adrien de Croy wrote:
> 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.

It's currently being used for WebSocket. Granted it breaks on a number
of intermediary but what was observed is a fast and clean failure,
which means that the client can fallback to the good old protocol.
Adding support for Upgrade to existing components is quite easy so
most products will evolve to correctly support WebSocket and will
provide you with Upgrade for free.

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

It's not designed for origin server usage, and is not reliable across
intercepting proxies, because it's a proxy-only method which is detected
by some proxies. I've experimented with that at one mobile phone operator
too. Sending a CONNECT on port 80 (which was intercepted by a modified
Squid) would simply result in a hang, probably because the outgoing
connection did not look like HTTP and was not sent to the proper components.

> 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.

Which is why you suggested the "GET https://" scheme which I agree with.

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

+1.

> 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.

It could be a good idea though it would require one additional round trip,
and would still not indicate whether intermediaries correctly support the
same features.

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

POP, SMTP etc are hop-by-hop. HTTP is end-to-end with invisible hops
everywhere and their own incomplete implementation. *this* is the problem.
Regarding this, PHK is right that if we want correct implementations of
the next spec, it should be short and easy to understand.

Willy

Received on Thursday, 26 January 2012 23:11:56 UTC