Re: #385: HTTP2 Upgrade / Negotiation

I know this has been said before by the Chrome team, but I too am starting
to see websocket bugs pile up due to transparent proxies that don't speak
upgrade and explicit proxies that don't let you tunnel to port 80 as
configured. (bluecoat and MS ISA/TMG are the most common I hear about).
ws:// hasn't been very successful in those environments but wss:// has
been. Good thing that in the websockets world there aren't a lot of legacy
urls to worry about - not true for http :(

For http2, I don't think it is enough to just fail fast to http/1 when for
most cases we could get those users speaking HTTP/2 over tls on 443. A
mechanism like Alternate-Protocol accomplishes that and I think that is a
more important property than upgrading in band (which is admittedly nice!).

As for caching successful upgrades or successful A-P's they pretty much
have the same set of tradeoffs.

-P

On Thu, Oct 25, 2012 at 3:02 AM, Gabriel Montenegro <
Gabriel.Montenegro@microsoft.com> 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?
>
> Gabriel
>
>