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

Re: usability of 100-continue, was: HTTP2 Expression of Interest : Squid

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Sat, 21 Jul 2012 11:31:45 +1200
Message-ID: <5009EA61.7030803@treenet.co.nz>
To: ietf-http-wg@w3.org
On 21/07/2012 7:20 a.m., Julian Reschke wrote:
> On 2012-07-20 21:09, Zhong Yu wrote:
>> Some small problems with the spec:
>>
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-20#section-4.6.14 
>>
>>
>> The meaning of 417 is vague. If a server isn't interested in the body
>> of a request with "Expect: 100-continue", SHOULD the server send 417?
>> I don't think so, there can be many reasons why the server isn't
>> interested in the body; it should send a specific response code
>> reflecting the real reason, e.g. 403.
>>
>> Server's intent that the client does not send the body is already
>> expressed by not sending 100 before the final code; there's no value
>> in 417 repeating that intent.
>>
>> Then 417 is only useful when the server cannot understand the 
>> expectation.
>
> Indeed. See also:
>
> "Upon receiving a request which includes an Expect header field with 
> the "100-continue" expectation, an origin server MUST either respond 
> with 100 (Continue) status code and continue to read from the input 
> stream, or respond with a final status code. The origin server MUST 
> NOT wait for the request body before sending the 100 (Continue) 
> response. If it responds with a final status code, it MAY close the 
> transport connection or it MAY continue to read and discard the rest 
> of the request. It MUST NOT perform the request method if it returns a 
> final status code." -- 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.6.4.3>
>
>> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-6.4.3 
>>
>> Requirements for HTTP/1.1 origin servers:
>>    ... (the server) MUST NOT perform the request method if it returns a
>> final status code (without a prior 100)
>>
>> That's too harsh, isn't it? Though the server doesn't need to read the
>> request body, that doesn't mean the request cannot be served. Maybe
>> the request headers contains sufficient information, and the request
>> body is just a redundancy measure.
>
> That appears to be an edge case not worth optimizing for.
>

In isolation this appears to be translatable as:
   MUST NOT perform method if final status (200) is returned without 
prior 100-continue (ie HTTP/1.0 hop erased Expect)

Amos
Received on Friday, 20 July 2012 23:32:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 23:32:28 GMT