Re: #327: Expect syntax

On 12/14/2011 01:19 PM, Julian Reschke wrote:
> 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.

It is not 100% clear what "expectation value" is in the above MUST
context. Just "expect-value" inside "expectation"? Or also
"expect-value" inside "expect-param"? Or anything inside "expectation"?
I suspect it is the latter but the addition of "-value" suffixes in BNF
made it less clear.

For example, if a server is able to comply with 100-continue but receives

    Expect: 100-continue; q=0

can that server assume that it is still able to comply or must it
respond with 417? Again, I suspect it is the latter.

Note that the BNF in RFC 2616 did not use "value" elements so it did not
raise similar "what is expectation value" questions.

Please consider replacing "any of the expectation values" with "any
expectations".


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

Technically, the above is ambiguous because both conditions could be
true. Not a big problem, but perhaps it should be polished since this is
a MUST. More on this below.


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

This paragraph kind of adds a third condition to the previous group of
MUSTs so it would be nice to merge them together:

  does not understand: 417
  understands but cannot meet: 417
  cannot parse: 4xx that is not 417

with some prioritization language to resolve conflicts when multiple
conditions apply at the same time.


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

In general, it is a bad idea to partially repeat a MUST specified
elsewhere. It raises questions whether this repetition for proxies
somehow annuls other related MUSTs when it comes to proxies (e.g.,
server MUST respond with 4xx if ...). It may be better to replace this
with something like:

    The Expect mechanism is hop-by-hop; the above server requirements
    apply to proxies.


> However, the Expect
>    header field itself is end-to-end; it MUST be forwarded if the
>    request is forwarded.

RFC 2616 does not have an explicit "end-to-end headers MUST be
forwarded" rule (AFAIK). If that problem is fixed in HTTPbis, there will
be (or already is) a similar "repeated MUST" concern here.


Thank you,

Alex.

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

Received on Wednesday, 14 December 2011 22:23:56 UTC