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 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.

>>> 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