- From: William A. Rowe, Jr. <wrowe@rowe-clan.net>
- Date: Tue, 16 Sep 2008 20:27:07 -0500
- To: Mark Nottingham <mnot@mnot.net>
- CC: Charles Fry <fry@google.com>, Mark Nottingham <mnot@yahoo-inc.com>, Julian Reschke <julian.reschke@gmx.de>, gears-eng@googlegroups.com, Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote: > > On 17/09/2008, at 10:21 AM, William A. Rowe, Jr. wrote: > >> Mark Nottingham wrote: >>>> the recipient of the entity MUST NOT ignore any Content-* (e.g. >>>> Content-Range) headers that it does not understand or implement and >>>> MUST return a 501 (Not Implemented) response in such cases. >>> (as 2616 does). >>> So, in theory you can PUT with Content-Range and know that if the >>> server doesn't support resumable requests, you'll get a 501. In >>> practice, of course, may be a completely different kettle of fish. >> >> The reason this isn't a solution is that the server must swallow the body >> of the request or lose keepalive and pipeline optimizations; 501 isn't an >> intermediate response. >> >> I wonder if a new 100-class code, the inverse of CONTINUE, wouldn't be of >> value in HTTP/next to designate that a the request body can be omitted >> since >> a final determination is available. The client would still have to >> send a >> body (since there is no ack) but using a chunked send, a chunk of 0 bytes >> to finalize an empty request body would be sufficient. > > Sounds nice, but I don't know that the introduced complexity is worth > keeping connections open in a fail case; implementers already seem to > have enough trouble with continue... :) Speaking of which, if 99.9% of the client implementors finally get their expect: 100-continue behavior correct by HTTP/next, it really wouldn't be impossible to suggest that this status for an HTTP/next request line must honor a 105 ABORT BODY response, even for a C-L: nnn based request.
Received on Wednesday, 17 September 2008 01:27:54 UTC