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

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

On Sat, 29 May 2010 18:51:41 +0200, Adam Barth <[e-mail]> wrote:

> I'll reply to your full email in detail later, but another note:
>
> On Fri, May 28, 2010 at 6:05 PM, Yngve Nysaeter Pettersen
> <[e-mail]> wrote:
>> IMO the specification should specifically comment on these issues, and
>> preferably allow clients to discard cookies with quotes that does not  
>> match
>> the quoted-string syntax,
>
> User agents already have the option to discard any cookie for any
> reason.  Adding this text to the spec would be redundant.

I think it may still be useful to point out specific issues where such  
discarding policies are used automatically. My impression of that text is  
that it focus more on cleanup and user controlled filtering, rather than  
what policies the client may have implemented. I suspect that most  
administrators will read it that way too. For example, the draft  
specifically mentions public suffix as a reason why a client can discard a  
cookie.

>> Perhaps one way to do that is to
>> specifically say that the result of using quotes in this fashion is
>> undefined?
>
> Leaving things like this undefined hurts interoperability.

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.

If we are going to document cookies as used on the Internet, then I think  
that includes pointing out the areas that should be avoided, particularly  
the ones where the results will be undefined. That should not just be done  
by how the syntax is defined, but also directly mentioning them.

This information can be mentioned either as notes (or Notes) in the  
definitions themselves, or collected in a separate "Implementation  
pitfalls"-section.

-- 
Sincerely,
Yngve N. Pettersen

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