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

On Fri, Jul 20, 2012 at 6:31 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 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)


"The server does not want the request body" has no logical implication
that "the server does not want the request". We shouldn't dictate what
the server must do here. It can do whatever it wants to with the
request, and what it actually did is reflected in the final response.

Zhong Yu

Received on Saturday, 21 July 2012 01:06:01 UTC