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

[Adam Barth <[e-mail]>]

On Mon, Feb 14, 2011 at 7:23 PM, Roy T. Fielding <[e-mail]> wrote:
> On Feb 4, 2011, at 11:29 AM, 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.
>
> Parsing for user agents is defined in section 5.  Servers have to
> parse cookies as well, and the grammar provided in section 4 is wrong
> for both generation and parsing.

I agree that the grammar depicted in Section 4 is not appropriate for
parsing.  That grammar is not for parsing.  It's for generation.
Perhaps we should add instructions for how servers should parse the
Cookie header?  That's absent from the current document.

As for generation, there's no exogenous notion of correctness.  We can
speak about usefulness, if you like, but correctness is endogenous to
this document.

> Why do you want to push forward a document with a known error in the
> grammar?  Just fix it.

I disagree that it's an "error."

> This is not a trivial detail.  As written, the specification says
> server developers SHOULD break sites like amazon.com.
>
>   cookie-value      = token / ""

Can you explain how the developers of site B using a restricted
grammar for generation will break amazon.com?  That seems entirely
non-sensical.

> The correct grammar is in the original Netscape cookie spec: "This
> string is a sequence of characters excluding semi-colon, comma and
> white space."  Which easily translates (conservatively) into
>
>   cookie-value      = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF
>
> and it does not conflict with section 5.

I've updated the draft to recommend the grammar below for generating
cookie-values:

cookie-value      = token / *base64-character
base64-character  = ALPHA / DIGIT / "+" / "/" / "="

Do you have a particular use case in mind for generating Set-Cookie
headers outside this grammar?

Adam