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: Henrik Nordström <henrik@henriknordstrom.net>
Date: Thu, 01 Mar 2012 02:22:01 +0100
Message-ID: <1330564921.24673.223.camel@home.hno.se>
To: ietf-http-wg@w3.org
ons 2012-02-29 klockan 16:26 -0800 skrev Mike Belshe:

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

Why on earth would it be slower than HTTP/1.1?

The only possible penalty compared to HTTP/1.1 is a request header more
in the initial request asking for upgrade.

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

It's one RTT if done right.

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

There is no round-trip penalty in Upgrade as long as the request
semantics you need can fit in HTTP/1.1. And if it can't then we are most
likely not talking about HTTP.


GET / HTTP/1.1
Host: www.example.com
Upgrade: HTTP/2.0

101 Switching Protocols
Upgrade: HTTP/2.0

HTTP/2.0 200 OK
Content-Type: text/html
Boundary: ====END===

<H1>Hello</H1>
====END====
GET /img HTTP/2.0
....


And a downgrade from HTTP/2.0 sent to a HTTP/1.1 server is

GET / HTTP/2.0
...

HTTP/1.1 505 HTTP Version Not Supported
....

GET / HTTP/1.1
...


There is a roundtrip in Upgrade if using it for STARTTLS, but then
because one maybe do not want to send the initial request ouside the TLS
wrapper so the initial request is may be a dummy one such as OPTIONS *.
If there is no need to secure the content of the initial request then
there is no RTT penalty for TLS upgrade either.

Regards
Henrik
Received on Thursday, 1 March 2012 01:22:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT