- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 01 Mar 2012 14:40:54 +1300
- To: <ietf-http-wg@w3.org>
On 01.03.2012 13:39, Mike Belshe wrote: > 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. That is what bothers me about all the arguments against Upgrade: based on extra RTT and lag. today: HTTP/1.1 request + HTTP/1.1 response == 1 RTT versus tomorrow: HTTP/1.1 request /w Upgrade header + XYZ response /w 200 status prefix == 1 RTT Assuming that native XZY is more efficient than HTTP/1.1. Where is the _loss_? All I see here is a gain of one responses XZY benefits. > > 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!) What type of server accepts an invalid format then does not reply? This is where a response in some supported format, at HTTP or TCP layer gets sent back immediately. There is no timeout. Could this perhapse be a side effect of using TLS and compression in SPDY? both of those would mask the internal syntax invalidity somewhat. > > It all comes down to perf, though. The upgrade round trip is sure > death. > What RTT? AYJ
Received on Thursday, 1 March 2012 01:41:21 UTC