W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: [google-gears-eng] Re: Deploying new expectation-extensions

From: William A. Rowe, Jr. <wrowe@rowe-clan.net>
Date: Tue, 16 Sep 2008 20:27:07 -0500
Message-ID: <48D05CEB.7030808@rowe-clan.net>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:37 UTC