Re: #327: Expect syntax

On 2011-12-14 23:20, Alex Rousskov wrote:
> 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.

And looking at this, that error code will always be 417, right? Thus 
that text can be simplified.

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

Yes.

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

Actually, the 4xx part isn't needed here. It's not specific to Expect:.

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

Doesn't is just repeat what was said before? I think it can be dropped 
as well.

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

Yes, we can just state that the requirements apply to all *recipients*.

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

"It always said that" :-) Not sure what we should do here.

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.

    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
    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 Wednesday, 14 December 2011 23:10:28 UTC