W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: Prefer Draft Feedback

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Tue, 06 Dec 2011 12:13:25 -0700
Message-ID: <4EDE6955.1060601@measurement-factory.com>
To: James Snell <jasnell@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:50 GMT