Re: [http-state] parser rules of draft-ietf-httpstate-cookie-22

[Adam Barth <[e-mail]>]

On Thu, Feb 24, 2011 at 2:21 PM, Roy T. Fielding <[e-mail]> wrote:
> On Feb 24, 2011, at 1:50 PM, Adam Barth wrote:
>> On Thu, Feb 24, 2011 at 1:31 PM, Roy T. Fielding <[e-mail]> wrote:
>>> If we would like to limit the use of DQUOTE to how it was limited
>>> in prior RFCs (matching outer pair), then I suggest
>>>
>>>  cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
>>>  cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-7E
>>>
>>> since that does cover all current usage that I am aware of and
>>> doesn't allow for odd usages of DQUOTE that might be misinterpreted
>>> by parsers that did not implement the Netscape spec but did
>>> implement one of the RFCs.
>>
>> DQUOTE is a cargo cult.  Matching DQUOTEs, as above, are less
>> problematic although they do have interoperability problems.  For
>> example, some user agents will incorrectly parse
>>
>> Set-Cookie: foo="bar\"; Secure
>>
>> (allowed by the grammar above) and will not interpret this header as
>> containing a Secure cookie.  If you insist on DQUOTE, we'll probably
>> be better off excluding %x5C from cookie-octet.
>
> Right, that's because the RFCs allowed backslash quoting by referring
> to the quoted-string production of HTTP.  Given the choice, I'd rather
> lose backslash than DQUOTE.  I haven't seen any Windows pathnames
> included in cookie values and sending such data would be unwise.
> Excluding %x5C should be okay.
>
>  cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
>  cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
>                   ; ASCII characters excluding CTLs, whitespace,
>                   ; DQUOTE, comma, semicolon, and backslash

Works for me.  Thanks Roy.

Adam