Re: #385: HTTP2 Upgrade / Negotiation

Hi Sal,

On Thu, Oct 25, 2012 at 01:02:34PM +0300, Salvatore Loreto wrote:
> >>This is the scenario:
> >>1. client has no prior knowledge whether this server supports http2 on 
> >>this port in the clear.
> >>2. client performs Upgrade (presumably, he'd be using NPN if over SSL)
> >>3. server sends 101 back.
> >>4. they now speak http2, and the client learns that this server speaks 
> >>http2 at this port.
> >>5. time passes, and this http2 connection goes away.
> >>6. a subsequent message from client to server (without a pre-existing 
> >>http2 connection) could bypass the Upgrade and send http2 frames directly.
> >>
> >>This would require the server to be able to detect if any given message is
> >>either http 1.X or http 2. Given the binary framing of the latter, it 
> >>seems
> >>possible to figure out how to make this unambiguous at the server.
> >>
> >>Comments?
> >This cannot work in environment where transparent protocol analysers and
> >intercepting proxies are installed.
> just to clarify
> the bad is not with the intercepting proxies in general,
> but only with the one that would expect a connection always starting 
> with an Upgrade
> However if we will standardize the possibility that an HTTP connection 
> can start directly
> from HTTP/2.0 then the intercepting proxy should not stop it
> and then the Gabriel proposal may or may not work for other reasons...

HTTP/1.1 intercepting proxies will block if there is no HTTP/1.1 header
prepended to the request. That's the point I'm making. And as I said in
an earlier mail, I don't really see the point in trying to optimize for
a handshake-less 2.0 connection over plain text since we already have
this possibility with TLS NPN. So I'd suggest that for clear text we
always have the Upgrade handshake prefix to remain compatible with the
HTTP/1.1 infrastructure in place, we could possibly optimize the handhsake
so that the client does not wait for the server's response once it knows
the path supports it, and for usages where we want to get rid of the
Upgrade handshake, then we use TLS where the equivalent of the Upgrade
handshake may be performed by the NPN extension.

> >- I was aware of an ISP combining haproxy + squid to save on bandwidth 
> >costs.
> >   The principle was very simple, haproxy was set up as an intercepting 
> >   proxy
> >   at the border, and balanced the load across a squid farm. Haproxy was
> >   configured to bypass squid for websocket since there was no added value
> >   in solliciting the caches for this. Haproxy doesn't understand 
> >   websocket,
> >   it only understands HTTP/1.1 and its associated Upgrade mechanism. If 
> >   you
> >   start sending non-HTTP/1.1 frames at it while it expects HTTP, you can 
> >   be
> >   sure to get a 400/badreq quickly in return (at least once the protocols
> >   diverge).
> that is WebSocket specific that only specifies and mandate the HTTP/1.1 
> Upgrade handshake
> so the Haproxy is acting correctly (and I had no doubt about it).

It's not specific, websocket uses the standard HTTP/1.1 Upgrade handshake,
precisely to be compatible with deployed components. And it works when
components comply with the standard. And for the same reason we cannot
decide to send raw WS frames over port 80 to a server which is known to
support WS, we cannot send raw HTTP/2 frames to a server which is known
to support HTTP/2, precisely because all we know is that intermediaries
are 1.1 compliant but not necessarily 2.0 compliant.

> >However I think we should experiment with the same principle as 
> >pipelining, ie
> >when a handshake has worked once, we can probably start sending HTTP/2 
> >frames
> >after the initial client handshake without waiting for a response since we 
> >know
> >that the whole path supports the Upgrade well.
> that would work in a desktop,
> but if you are using a mobile scenario you can not be so sure that whole 
> path is going
> to be use is exactly the old path that supported the Upgrade well.
> or I am missing something here?

That's the point I was making about the risk of changing the connection
method between the first and subsequent connections :-) If you reuse the
same mechanism for all connections, you have much less risk of failure
than if you change. I think we're saying the same thing in fact :-)

Cheers,
Willy

Received on Thursday, 25 October 2012 10:45:15 UTC