Re: #327: Expect syntax

On 2011-12-15 01:02, Alex Rousskov wrote:
> On 12/14/2011 04:09 PM, Julian Reschke wrote:
>
>> I now have:
>>
>> 9.3.  Expect
>>
>>     The "Expect" header field is used to indicate that particular server
>>     behaviors are required by the client.
>>
>>       Expect       = 1#expectation
>>
>>       expectation  = expect-name [ BWS "=" BWS expect-value ]
>>                                  *( OWS ";" OWS expect-param )
>>       expect-param = expect-name [ BWS "=" BWS expect-value ]
>>
>>       expect-name  = token
>>       expect-value = token / quoted-string
>>
>>     A recipient that does not understand or is unable to comply with any
>>     of the expectations in the Expect header field(s) of a request MUST
>>     respond with a 417 (Expectation Failed) status code.
>
> You essentially dropped the 4xx part for invalid Expect headers. That
> simplified the specs a lot, but I am not sure we can do that because
> "does not understand" and "unable to comply" do not necessarily cover
> "cannot parse".
>
> You have argued that inability to parse a header field is covered

Covered in that we say "it depends".

> elsewhere. I am not well versed in HTTPbis yet, but I doubt this is
> true. There are probably no requirements that a server MUST respond with
> an error if it cannot parse Date or other non-critical headers. We need
> an _explicit_ rule to make Expect critical. I suspect that is why there
> was an explicit "MUST respond with ... 4xx" rule here in RFC 2616.

Probably. Will adjust.

> Consider the following text:
>
> If all received Expect header field(s) are syntactically valid but
> contain an expectation that the recipient does not understand or cannot
> comply with, the recipient MUST respond with a 417 (Expectation Failed)
> status code. A recipient of a syntactically invalid Expectation header
> field MUST respond with a 4xx status code other than 417.

400?

>>     The only expectation defined by this specification is:
>>
>>     100-continue
>>
>>        Defined in Section 6.2.3 of [Part1]
>>
>>     Comparison is case-insensitive for names (expect-name), and case-
>>     sensitive for values (expect-value).
>>
>>     The Expect mechanism is hop-by-hop: the above requirements apply to
>>     any component receiving requests.  However, the Expect header field
>
> I would replace "any component receiving requests" with "any receiving
> agent, including proxies" or with "any server, including proxies" to use
> terminology established in HTTPbis part 1.

Thanks for the feedback; will send out a new proposal later today.

Best regards, Julian

Received on Thursday, 15 December 2011 09:30:55 UTC