- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 5 Dec 2013 17:09:50 +1100
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 5 Dec 2013, at 3:51 pm, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: > On Wed, Dec 04, 2013 at 12:11:24PM -0800, Martin Thomson wrote: >> Yes, we apologize for the delay in getting this all ready, but it's out now. >> >> - We've expanded the text on 1xx > > Is that text on 1xx (specifically on translation behaviour) in accordance > with HTTP/1.1 specs? > > 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? > 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. > 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). > > In HTTP/1.1, such app would presumably use zero buffers, so point > of no return is actually starting to send the data. > > -Ilari > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 5 December 2013 06:10:22 UTC