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

On Thu, Dec 05, 2013 at 10:11:22AM -0800, Martin Thomson wrote:
> On 4 December 2013 22:37, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> >
> > Without positive acknowledgement one needs to timeout on success case
> > before one can send unbuffered part.
> 
> 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.

Well, and clients that fail if any error happens after >N (including
case where N=0) bytes have been sent. Whereas for errors before
that point, the client can auto-resubmit with header modifications
(e.g. adding authentication).

And yes, such things do exist. And the standard way to handle this in
HTTP/1.1 is Expect: 100-Continue (plus maybe hacks for servers that
don't support it, the proper term for such hacks tends to be "Charlie
Foxtrot").

This is not about saving bytes nor roundtrips. 


As for doing this even with special server support in HTTP/2.0, how
could server signal (including through (most) middleboxes!) that it
considers sent headers OK (NAKing can be done with sending final response)?
New end-to-end frame type (of course, most client APIs are probably not
going to like that...)?


-Ilari

Received on Thursday, 5 December 2013 20:11:45 UTC