W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: I-D Action: draft-ietf-httpbis-http2-09.txt

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 5 Dec 2013 10:11:22 -0800
Message-ID: <CABkgnnWdrwCEqp=BRXM_sr76aBNutTHzzc9Kvp6x0GAyx=BOtg@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 4 December 2013 22:37, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>> The server can send a final status code at any time, with HTTP/1 or HTTP/2.
>> The client can choose whether to start sending the body or hold back, both
>> with HTTP/1 and HTTP/2.
>
> Well, final status codes mid-body are somewhat unlikely, and would likely
> be caused by problems in the body itself (or server bugs).
>
> Without positive acknowledgement one needs to timeout on success case
> before one can send unbuffered part.

Yes, this is correct.  Losing 100 means that you don't get an
acknowledgement.  But why would you hold back?  The server has a
receive window that protects it from unwanted request bodies; just
send.  If it doesn't want it, you will get a response or a stream
cancellation.

Note that a server that wants 100 continue-equivalent behaviour can
set an initial window size for stream of zero.

The only drawback is for clients that want to save bytes.  Those
clients can implement a timeout of ~1RTT if they want to avoid that
cost.  That's the only downside from removing 1xx support.  There's a
lot of upside though.
Received on Thursday, 5 December 2013 18:11:49 UTC

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