Re: #327: Expect syntax

On 2011-12-15 22:10, Julian Reschke wrote:
> On 2011-12-15 01:02, Alex Rousskov wrote:
>> ...
>
> Again, thanks for the feedback. I used the text you suggested and now have:
> ...

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)

- state that 100-continue doesn't have expect-params

The change is committed with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1494>, and the 
text now says:

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.


Best regards, Julian

Received on Friday, 16 December 2011 21:15:29 UTC