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

[Peter Saint-Andre <[e-mail]>]

On 2/10/11 6:09 PM, Adam Barth wrote:
> 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

WFM, and that seems to capture list discussion.

Adam, I'll follow up with the remaining IESG members this week and
perhaps ask you to submit a revised I-D so we can finish this off. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/