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

[Adam Barth <[e-mail]>]

On Thu, Feb 24, 2011 at 1:31 PM, Roy T. Fielding <[e-mail]> wrote:
> On Feb 24, 2011, at 1:01 PM, Peter Saint-Andre wrote:
>> On 2/23/11 10:16 PM, Adam Barth wrote:
>>> On Wed, Feb 23, 2011 at 5:01 PM, Roy T. Fielding <[e-mail]> wrote:
>>>> On Feb 23, 2011, at 2:57 PM, Peter Saint-Andre wrote:
>>>>> On 2/23/11 3:07 PM, Roy T. Fielding wrote:
>>>>>
>>>>> <snip/>
>>>>>
>>>>>> Therefore, I would like you to change the ABNF so that it
>>>>>> reflects the reality of (Set-)Cookie usage on the Internet,
>>>>>> for the same reason that you have insisted the algorithm
>>>>>> for user agent parsing reflects reality.  Changing the ABNF
>>>>>> to include base64 does not do that -- it is just another
>>>>>> fantasy production that differs from all prior specs of
>>>>>> the cookie algorithm.  Changing it to
>>>>>>
>>>>>> cookie-value      = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF
>>>>>>
>>>>>> or just the minimum
>>>>>>
>>>>>> cookie-value      = %x21-2B / %x2D-3A / %x3C-7E
>>>>>
>>>>> Hi Roy,
>>>>>
>>>>> The latter seems fine, and in conversation with Adam he indicated to me
>>>>> that he would not object to such a change.
>>>>
>>>> Okay by me.
>>>
>>> One nit: I would exclude %x22 because there are interoperability
>>> problems with cookie-values that contain %x22.
>>
>> So:
>>
>> cookie-value    = %x21 / %x23-2B / %x2D-3A / %x3C-7E
>>
>> If there are no objections, I'll add an RFC Editor note to that effect.
>
> There have already been objections -- that is what started this thread.
>
> %x22 is DQUOTE.  I am not aware of any interoperability concerns
> with the use of DQUOTE in opaque cookie values, though I can
> understand why they might be a concern.  However, use of them as
> a quoted-string value (where browsers store the DQUOTEs as more
> opaque data) is extremely common because the past two RFCs defined
> the value as token / quoted-string.
>
> I just noticed a grammar bug in my suggestion. It should have been
>
>  cookie-value      = *( %x21-2B / %x2D-3A / %x3C-7E )
>
> 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.

On Thu, Feb 24, 2011 at 1:46 PM, Remy Lebeau <[e-mail]> wrote:
> My original problem with DQUOTE handling, and is still a concern for me, is that the current draft does not allow the use of DQUOTE around attribute values at all, let alone around cookie values. DQUOTE around attribute values is common to see because it is part of RFC 2109, and it cannot be treated as opaque data like it can in cookie values. The grammer rules for parsing attributes must allow for recognizing and removing DQUOTE when extracting attribute values.

Based on data about how cookies are used on the Internet and studying
the behavior of existing user agents, we need only tolerate DQUOTE in
the Expires attribute, which the current draft does.  In no case is it
advantageous for a server to send DQUOTE.

Adam