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

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:
>> 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." -- 
> <>
>> 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)


Received on Friday, 20 July 2012 23:32:20 UTC