Re: [http-state] Comments on draft-ietf-httpstate-cookie-08

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

On Sun, 30 May 2010 22:48:16 +0200, Adam Barth <[e-mail]> wrote:

> On Fri, May 28, 2010 at 6:05 PM, Yngve Nysaeter Pettersen
> <[e-mail]> wrote:
>> Here are some more comments about the httpstate draft.
>

>> - %XX escaping and path compares. Maybe add a reference to the URI  
>> compare
>> definition in 2616?
>
> Can you provide a test case that demonstrates that %-escaping is
> relevant in this context?  My testing shows that user agents ignore
> %-escaping in the Path attribute.  Now, some user agents canonicalize
> %-escaping in URLs, but that's a matter best left to another working
> group, IMHO.

target URI is /foo/%41/bar, path is /foo/a/

>> As for the server-side, when sending this header
>>
>>   Cookie:  name1="foo1; name2=bar"; name3=foo2"2; name4=bar"4; name5=foo
>>
>> to Django 1.1 or the Python 2.6 Cookie module, the result is the  
>> following
>> set of cookies:
>>
>>   name1="foo1; name2=bar"
>>   name3=foo2
>>   name4=bar
>>   name5=foo
>
> That's only an issue if Django sends a Set-Cookie header that
> generates that Cookie header.  If somewhere there's a Django server
> that does send such a Set-Cookie header, the author of that server is
> likely expecting the Cookie header to parse that way because that's
> how it works for the majority of user agents.  If they aren't
> expecting that parsing, they'll discover it as soon as they test their
> site with any version of IE.

You are assuming that Django is the only framework involved in the system.  
And AFAICT this behavior comes from *Python's* module for cookie handling,  
and is *not* Django-only, meaning that potentially all Python based  
systems could encounter this problem. And keep in mind that this was just  
the frameworks I had immediately at hand, it may well be (probably very  
likely) that other frameworks are behaving in the same fashion.

I think it is quite possible that a parser such as Django/Python's can be  
integrated into an existing system that under some circumstances use  
unbalance quotes by another system. If so, testing might not reveal the  
issue until much later. One possibility is that the cookie's value is  
directly or indirectly derived from user input (which could be very  
dangerous in any case).

> By contrast, if we adopt Opera's parsing of the Set-Cookie header,
> then we're much more likely to cause interoperability problems for
> sites that rely on the more common parsing.

Not too frequently I suspect; I can recall only one, maybe two, cases (and  
the one I remember showed up in my mailbox last week)

>> The situation for this particular value syntax is already undefined, and
>> while it is a corner case, it can have unanticipated effects,  
>> particularly
>> in combination with different cookie ordering algorithms. Putting the  
>> server
>> administrators on notice about the issue should hopefully increase
>> interoperability because they can then avoid the problematic cases.
>
> The behavior for this particular value syntax is indeed defined.  You

By "undefined" I mean that there are already deployed systems that behave  
in different fashions from what might be expected if unbalanced quotes are  
used.  Perhaps "the result is unpredicatable" would be a better  
description.

> can find the definition in Section 5.  We're already advising server
> administrators not to use double-quotes.  That's the most helpful

Not in that many words, but it is admittedly implied by the token  
specification of cookie-value. I think that in this case it is better to  
have a little redundancy by pointing out that this is one character where  
the "opaque" part is ignored by a number of clients (and may be ignored by  
serverside frameworks), and we are not just talking about Opera, we are  
also talking about a major client like FireFox 3.6 and earlier versions  
(whether or not nightlies have changed behavior in this area)


-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************