Re: #385: HTTP2 Upgrade / Negotiation

On 10/25/12 10:29 AM, Willy Tarreau wrote:
> 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.
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...


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

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

br
/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

Received on Thursday, 25 October 2012 10:03:00 UTC