Re: #385: HTTP2 Upgrade / Negotiation

Hi Gabriel,

On Thu, Oct 25, 2012 at 07:02:34AM +0000, Gabriel Montenegro wrote:
> > On the other hand, the Upgrade-based negotiation is pessimistic; it assume
> > that something will go wrong until we prove that both ends speak the same
> > language. It'll be fast but have some limitations at the start (as discussed).
> 
> I've been thinking about this, and think we may be able to make it more optimistic after the first exchange.
> 
> 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. The first success only means one thing,
which is that the scenario used along the whole path works, it does not
preclude that changing the opening handshake would too woke. Two examples :

- in March I informed the hybi WG that I got a report from a user that
  Trend Micro's OfficeScan installed on his machine was blocking WS
  upgrades because it was analysing exchanges between the browser and
  the outer world and did not like 101 responses. When this program
  is eventually fixed, it will still inspect contents and expect HTTP
  to be spoken there, which would not be the case on the second handshake ;

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

So what we learn from the first successful connection is that we should
continue to use the same mechanism.

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.

Regards,
Willy

Received on Thursday, 25 October 2012 07:30:33 UTC