W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

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

From: Mike Belshe <mike@belshe.com>
Date: Wed, 29 Feb 2012 16:39:39 -0800
Message-ID: <CABaLYCvVnGbEwpWhnjr8HNq_ORf2Lyjct-hdhbYKpnKAqd=6kg@mail.gmail.com>
To: Henrik Nordström <henrik@henriknordstrom.net>
Cc: ietf-http-wg@w3.org
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.


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
Received on Thursday, 1 March 2012 00:40:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC