Re: Prefer Draft Feedback

On Tue, Dec 6, 2011 at 8:29 AM, Alex Rousskov
<rousskov@measurement-factory.com> wrote:
> On 12/05/2011 05:32 PM, James Snell wrote:
>> Ok... updated the draft based on much of the feedback provided. There
>> will be another round of changes coming. Hopefully I've adequately
>> addressed most of the concerns raised so far.
>>
>> http://tools.ietf.org/html/draft-snell-http-prefer-05
>
>
>>      Prefer           =  "Prefer" ":" 1#preference
>>      preference       = OWS preference-token OWS *prefer-params OWS
>>      preference-value = token / quoted-string
>>      preference-token = token OWS [ "=" OWS preference-value OWS ]
>>      prefer-params    =  ";" OWS preference-token
>
> Looking at HTTPbis Part 1 examples, some of the above OWS should
> actually be BWS (i.e., something that should not be there).
>
> Furthermore, HTTPbis already defines OWS for #rules (Section 1.2.1). I
> think you can reuse that without explicitly adding so many OWSs.
>
> I would not call a 'name = "foo bar"' string a "token" but
> preference-token does.
>
> preference-value should probably be defined after use, for clarity and
> symmetry with other top-down definitions.
>
> The prefer-params name implies multiple parameters but defines only one.
>
> How about this:
>
>  Prefer     = "Prefer" ":" 1#preference
>  preference = name [ BWS "=" BWS value ] *parameter
>  parameter  = OWS ";" OWS name [ BWS "=" BWS value ]
>  name       = token
>  value      = token / quoted-string
>

That works.

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

>> 7. The "wait" Preference
>>
>>
>>    The "wait" preference can be used to establish an upper bound on the
>>    length of time, in seconds, the user-agent is willing to wait for a
>>    response, after which the user-agent may choose to abandon the
>>    request.
>
> Do you have to limit this feature to user-agents?
>
> A caching proxy in a poor connectivity environment may want to use this
> mechanism to respond with a cached stale response if it cannot get a
> fast fresh response from the server, for example. Such a proxy will work
> well with user-agents that do not support Prefer.
>
> It seems to me that replacing most occurrences of "user-agent" with
> "client" will not harm your specification and may make it more generally
> useful.

Ok, I can definitely do that.

>
>>      wait = "wait" OWS "=" OWS delta-seconds
>
> I think HTTPbis wants you to use BWS here.
>

Ok, good to know.

>
> HTH,
>
> Alex.


Definitely helpful, thank you for the feedback.

Received on Tuesday, 6 December 2011 18:44:15 UTC