#327: Expect syntax, was: Prefer Draft Feedback

On 2011-12-06 20:13, Alex Rousskov wrote:
> On 12/06/2011 11:43 AM, James Snell wrote:
>> On Tue, Dec 6, 2011 at 8:29 AM, Alex Rousskov wrote:
>>> Overall, the Prefer grammar is more complex than any similar construct I
>>> saw in HTTPbis Part 1 or Part 6! If I did not miss any existing cases,
>>> would it be possible to simplify the Prefer grammar so that existing
>>> parsing code and data structures can be reused to deal with it?
>
>> The grammar for Prefer is modeled closely after the Expect header
>> field grammar in Part 2 and adds only the allowance that a preference
>> can have it's own value (e.g. "Prefer: wait=10" ...
>
> As Julian pointed out, expectation-extension in RFC 2616 attempts to use
> the same syntax:
>
>>    Expect       = 1#expectation
>>
>>    expectation  = "100-continue" / expectation-extension
>>    expectation-extension = token [ "=" ( token / quoted-string )
>>                             *expect-params ]
>>    expect-params = ";" token [ "=" ( token / quoted-string ) ]
>
> The only difference I see is that expect-params are only allowed for
> expectations that start with name=value but I bet that is just a bug
> with the closing ']' placement in expectation-extension definition
> (something for HTTBis to fix?).
>
> If expectation-extension is fixed, we would have to support the same
> syntax for Expect, my "this is too complex!" comment would be
> essentially wrong, and you can have the nice-looking wait=10 preference.
> ...

Here's an attempt to clean up Expect:

- fixes the grammar to allow params for value-less expectations

- re-adds whitespace (lost during ABNF update)

- untangles the predefined value 100-continue from the ABNF

The whole paragraph would be:

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 server that does not understand or is unable to comply with any of
    the expectation values in the Expect field of a request MUST respond
    with appropriate error status code.  The server MUST respond with a
    417 (Expectation Failed) status code if any of the expectations
    cannot be met or, if there are other problems with the request, some
    other 4xx status code.

    This header field is defined with extensible syntax to allow for
    future extensions.  If a server receives a request containing an
    Expect field that includes an expectation that it does not support,
    it MUST respond with a 417 (Expectation Failed) status code.

    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 is case-
    sensitive for values (expect-value).

    The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
    return a 417 (Expectation Failed) status code if it receives a
    request with an expectation that it cannot meet.  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.

(see 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/327/327.diff>)

Feedback appreciated, Julian

Received on Wednesday, 14 December 2011 20:19:51 UTC