Re: [http-state] Is this an omission in the parser rules of draft-ietf-httpstate-cookie-21?

[Adam Barth <[e-mail]>]

On Thu, Feb 10, 2011 at 4:59 PM, Peter Saint-Andre <[e-mail]> wrote:
> On 2/4/11 12:29 PM, Adam Barth wrote:
>> On Fri, Feb 4, 2011 at 11:24 AM, Roy T. Fielding <[e-mail]> wrote:
>>> On Feb 4, 2011, at 10:51 AM, Adam Barth wrote:
>>>> On Fri, Feb 4, 2011 at 10:47 AM, Remy Lebeau <[e-mail]> wrote:
>>>>> -------- Original Message --------
>>>>> Subject: Re: [http-state] Is this an omission in the parser rules of
>>>>> draft-ietf-httpstate-cookie-21?
>>>>> From: Adam Barth
>>>>> Date: Fri, February 04, 2011 10:19 am
>>>>> To: Remy Lebeau
>>>>> Cc: [e-mail]
>>>>>
>>>>>> The draft gives user agents precise
>>>>>> instructions for how to parse all
>>>>>> manner of cookies, including cookies with
>>>>>> values that contain quote characters. That
>>>>>> information is contained in Section 5
>>>>>
>>>>> I have re-read Section 5 and I do not see its grammar or parsing rules
>>>>> accounting for quoted-string values at all. It only says to remove WSP
>>>>> characters surrounding extracted names and values, and quote characters
>>>>> are not part of the WSP definition. So what am I missing? Where exactly
>>>>> does it say how to unquote a quoted-string used in attribute values?
>>>>
>>>> Precisely.  It does not say to unquote a quoted-string because that's
>>>> not how cookies work.  The role of the quote character is cookies is
>>>> identical to the role of the "!" character.  That is, neither play a
>>>> special role in the protocol.  Any representations by the contrary by
>>>> 2109 or any other document are fiction and have only caused pain and
>>>> misery in the world.
>>>
>>> That may be, but the grammar for server generation of set-cookie
>>> values is clearly wrong because use of DQUOTE in cookie values is
>>> common (roughly 10% of the values in my browser cookie store) and
>>> previously defined, even if we consider DQUOTE to be part of the
>>> value string.  Let's just change the generating grammar for value to
>>> match how cookies are actually parsed and only exclude characters
>>> that are known to cause failures.
>>
>> The grammar is not used for parsing.  Parsing is defined in Section 5,
>> not Section 4.
>
> Right. And I think the revised text in version -21 (with revisions to
> address the IESG comment from Robert Sparks) makes that fairly clear.
>
> Adam, did you propose specific text addressing Dan Winship's original
> issue about "cookie-value=token"? As far as I can see, that's the only
> substantive issue raised in this thread, but I admit that I might have
> missed something.

Sure:

diff --git a/drafts/cookie.xml b/drafts/cookie.xml
index e0a53f3..17cc0a5 100644
--- a/drafts/cookie.xml
+++ b/drafts/cookie.xml
@@ -335,7 +335,8 @@ set-cookie-header = "Set-Cookie:" SP set-cookie-string
 set-cookie-string = cookie-pair *( ";" SP cookie-av )
 cookie-pair       = cookie-name "=" cookie-value
 cookie-name       = token
-cookie-value      = token / ""
+cookie-value      = token / *base64-character
+base64-character  = ALPHA / DIGIT / "+" / "/" / "="
 token             = <token, defined in [RFC2616], Section 2.2>

 cookie-av         = expires-av / max-age-av / domain-av /
@@ -370,7 +371,7 @@ extension-av      = <any CHAR except CTLs or ";">

           <t>To maximize compatibility with user agents, servers that wish to
           store arbitrary data in a cookie-value SHOULD encode that data, for
-          example, using Base 16 <xref target="RFC4648" />.</t>
+          example, using Base64 <xref target="RFC4648" />.</t>

           <t>The portions of the set-cookie-string produced by the cookie-av
           term are known as attributes.  To maximize compatibility with user

Adam