Re: #385: HTTP2 Upgrade / Negotiation

On 24 October 2012 14:44, Mark Nottingham <mnot@mnot.net> wrote:

>
> > One possible way to mitigate this would be to combine the Upgrade header
> approach with a new Expect token. For instance...
> >
> >   POST /default.htm HTTP/1.1
> >   Host: server.example.com
> >   Connection: Upgrade
> >   Upgrade: HTTP/2.0
> >   Expect: 101-upgrade
> >
> > The addition of the Expect header does two things...
> >
> > 1. It makes the upgrade a requirement rather than optional...
> > 2. The client would then wait as reasonable time for the 101 Switching
> Protocols before it proceeds to send the http/2.0 encoded data...
> >
> > When the client does start sending the data (after receiving the 101
> response), it would do so by first sending a SYN_STREAM.. To http/1.1
> servers, this would appear to be nothing more than regular POST payload
> data. For http/2 traffic, this requires an initial round trip but it
> addresses the upgrade on payload-bearing request issue... and is exactly
> the kind of thing the Expect header was intended for. The scheme is
> obviously far from perfect, however.
>
> Hm. I'd be interested to hear from implementers on this. The only
> advantage that I see is that you'd be able to start multiplexing other
> requests on the same connection sooner. However, you could also just use
> SRV, or a different connection if it's not available.



Sorry for slow response - been out of the loop for a few weeks.

As an implementer, this kind of upgrade is fine for new server
implementations, but I don't think it helps much.

If the client wants to assume success of the upgrade and start sending
http/2 frames before the 101, then that could easily be handled by a new
server regardless of METHOD.    Having the POST there does not really
change the situation, and I'd actually prefer it if the method was left to
be the real method, so that the server could send a valid response after
the 101 as a http/2 frame (eg if the upgrade is in a GET /index.html
request then the first frames back could be a push of the index.html
content or a 304 etc.).

Using a POST to make subsequent HTTP/2 frames sent by the client look like
a body to a HTTP/1 server/infrastructure is fraught with issues and buys us
very little. Most site interactions commence with a single request and it
is only once content for that request is received that the client will
start generating demand for more requests in parallel.  So that demand
coincides with knowing if the upgrade was successful or not, so the
protocol is known.

So let's totally avoid sending http/2 frames to http/1 servers and getting
into the whole how-might-it-be-interpreted debate that stalled the hybi-wg
for over a year.

So long as the server is able to push a response to the upgraded request
immediately after the 101 (along with a push of any other expected
content), then I think upgrade along the lines of
http://tools.ietf.org/html/draft-montenegro-httpbis-http2-negotiation-00can
be a good low latency way to establish a HTTP/2 connection.

There may be some other use-cases that do need to open many http/2 mux
streams in parallel immediately, but they are not from normal browsers, so
I think we can address them with the optimisation ideas for making direct
HTTP/2 connections (DNS, new port etc.).

cheers





-- 
Greg Wilkins <gregw@intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.