- From: Henrik Nordström <henrik@henriknordstrom.net>
- Date: Thu, 01 Mar 2012 02:22:01 +0100
- 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 UTC