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

On Thu, Dec 05, 2013 at 05:09:50PM +1100, Mark Nottingham wrote:
> On 5 Dec 2013, at 3:51 pm, Ilari Liusvaara <> wrote:
> > On Wed, Dec 04, 2013 at 12:11:24PM -0800, Martin Thomson wrote:
> > 
> > Also, If HTTP/1.1 (only!) client tries to do large streaming PUT/POST
> > to possibly auth'd URL, and there is a proxy that does that sort of
> > games, things just plain are going to fail.
> What do you mean by "that sort of games" here?

Synthetizing 100 response (yes, that would also happen with HTTP/1.0
servers, but usually people aren't doing PUT/POST of large things to

> > Also, large streaming PUT/POST to possibly auth'd URL can't be done
> > without expect-100 nor resorting to heuristic timeouts (framing
> > will not help here, apart from being able to send your buffers while
> > waiting, and with any sort of faster link, those buffers are going
> > to run out, forcing transfer pause).
> 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, often the whole transfer can be buffered (or the data regenerated),
but not always.

> > The problem is that there is a point of no return in such thing,
> > once past that, any error causes a failure without application being
> > to able to adjust the request (e.g. by adding authentication).
> Changing the request headers after the header block has terminated
> isn't possible in HTTP/1 (I mean, theoretically you could add trailers,
> but AFAIK this is completely un-interoperable).

If you still have the data needed to form a request, you can send another
one with problems (e.g. lack of auth) fixed.

But after certain point in some cases, one can't do that anymore.


Received on Thursday, 5 December 2013 06:37:42 UTC