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

["Roy T. Fielding" <[e-mail]>]

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

....Roy