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: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 01 Mar 2012 14:40:54 +1300
To: <ietf-http-wg@w3.org>
Message-ID: <d9f6b0a1a14c082d43114b2e0b41ccc8@treenet.co.nz>
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 GMT

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