Re: #327: Expect syntax

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
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.

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.


>    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.


Thank you,

Alex.



>    itself is end-to-end; it MUST be forwarded if the request is
>    forwarded.
> 
>    Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
>    Expect header field.
> 
> 
> Thanks for the feedback, Alex. Please have another look!
> 
> Best regards, Julian

Received on Thursday, 15 December 2011 00:05:50 UTC