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

[Adam Barth <[e-mail]>]

On Tue, Feb 15, 2011 at 5:46 PM, Adam Barth <[e-mail]> wrote:
> On Tue, Feb 15, 2011 at 3:55 PM, Roy T. Fielding <[e-mail]> wrote:
>> On Feb 15, 2011, at 2:05 PM, Adam Barth wrote:
>>> On Tue, Feb 15, 2011 at 1:22 PM, Julian Reschke <[e-mail]> wrote:
>>>> On 15.02.2011 22:11, Adam Barth wrote:
>>>>> ...
>>>>> You really think we should recommend that servers use invalid UTF-8
>>>>> sequences as cookie-values?  That sounds like bad advice...
>>>>> ...
>>
>> I am not recommending that they use invalid UTF-8 sequences.
>> The ABNF only tells the implementer what octets can be used
>> and what needs to be anticipated while parsing.  If I were
>> designing a new Cookie protocol, I would exclude the high bits,
>> but this is how the current Cookie protocol actually works in
>> practice.
>
> I feel like I'm just repeating myself.  The text you're complaining
> about does not define how to parse a Set-Cookie header.

To be crystal clear, this is the only text in the document that refers
to this figure:

          Servers SHOULD NOT send Set-Cookie headers
          that fail to conform to the following grammar:

Adam


>>>> Could you elaborate? Is there client code out there that assumes cookie
>>>> values to *be* UTF-8?
>>>
>>> Regardless of what client code exist, surely servers are better off
>>> avoiding non-ASCII characters in their cookie values.  Using non-ASCII
>>> characters in HTTP headers is just asking for trouble.
>>
>> It is irrelevant.  HTTP/1.x defined them as ISO-8859-1 and nothing
>> breaks by treating them as such.  This spec (and the Netscape spec)
>> defines them as an opaque array of data bytes and nothing breaks
>> by treating them as such.
>>
>> I don't know of any implementation that would expect them to be
>> UTF-8.  I do know that attempting to use a UTF-8 string parser to
>> parse an HTTP data stream is a known security hole, so there is
>> no point in worrying about breaking those parsers any further
>> than they would already be broken (if any still exist -- J2SE
>> fixed their holes last year).
>>
>> I don't have any objection to a sentence that says servers
>> SHOULD NOT send %x80-FF even though the grammar allows it.
>> But I don't see any need for it either given the apparent
>> interoperability shown by user agents.
>
> That's essentially what the current document says.  The only
> difference is that it also recommends that servers not generate
> characters such as %x24, whose role in cookies has been muddied by RFC
> 2965.
>
> Adam
>