Re: Review: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

If the protocol is allowed to be slower than HTTP/1.1, then you could do
this.  But, a lot of server operators that care about performance aren't
going to want to take that hit.

Also, if the browser records that your server was HTTP/2.0 in the past, and
now it downgrades to a non HTTP/2.0 response, the failure detection needs
to be quick.  If the frame format is different, depending on the way the
bytes flow, this could lead to a devastating timeout (30+ seconds for the
user to wait!)

It all comes down to perf, though.  The upgrade round trip is sure death.

mike




2012/2/29 Henrik Nordström <henrik@henriknordstrom.net>

> ons 2012-02-29 klockan 15:16 -0800 skrev Mike Belshe:
>
> > The problem with upgrade is that it costs a round trip of latency.
>
> Only if you are pipelining and then only on the second request, and
> pipelining on the first request is generally a bad idea anyway. So no.
>
> It's just means that the initial request (not it's response) is limited
> to HTTP/1.x wire format and that you can't pipeline if the protocol
> change means pipelined requests can not be properly parsed after the
> protocol change.
>
> And if HTTP/2.x preserve initial request-line structure compatibility
> with HTTP/1.x like it should then future requests to the same server
> should be able to assume the server is HTTP/2.x capable from start,
> until rejected, and you can even pipeline during the protocol upgrade if
> desired.
>
> Regards
> Henrik
>
>
>