W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: #327: Expect syntax

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Fri, 16 Dec 2011 14:56:42 -0700
Message-ID: <4EEBBE9A.6080604@measurement-factory.com>
To: Julian Reschke <julian.reschke@gmx.de>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 12/16/2011 02:14 PM, Julian Reschke wrote:

> OK, I did two more changes:
> - in the grammar, allow trailing semicolons; so that "100-continue;"
> isn't invalid (we have the same in Prefer)

Any specific reason to allow that trailing semicolon? Seems like it
should not be allowed unless Expect is already commonly used that way.

I cannot find it right now, but I think there was some text in HTTPbis
that talked about "cleansing" of header fields before
comparing/interpreting them (folding, removing BWS, and such). If that
text is indeed there somewhere, does it allow an implementation to
remove bare semicolon before comparing?

Finally, I expect some currently compliant implementations to fail
updated tests if a bare semicolon is allowed and must be ignored.

Thank you,


> 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
>    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
>       The "100-continue" expectation is defined Section 6.2.3 of
>       [Part1].  It does not support any expect-params.
>    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 server, including proxies.  However, the Expect header field
>    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.
Received on Friday, 16 December 2011 21:57:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:51 GMT