Re: Prefer Draft Feedback

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.


Thank you,

Alex.

Received on Tuesday, 6 December 2011 19:14:33 UTC