Re: [http-state] Updated draft

[Daniel Stenberg <[e-mail]>]

On Sat, 15 Aug 2009, Adam Barth wrote:

> http://www.ietf.org/id/draft-abarth-cookie-01.txt
>
> As always, comment appreciated.

A few comments:

Section 2 "Terminology" describes how the domain matchin is made. I know this 
was like this in RFC2965 as well, but I find it to be a weird placement for 
that description. That's not terminology, it's rather text meant for section 
6.4 in my opinion.

In section 6.3 I found this text:

"The user agent MUST evict a cookie ... if ... More than 50 cookies exist in 
the cookie store with the same domain field."

Is that really a MUST? There's no fixed 50 cookies limit in curl at least and 
I would be surprised if all other HTTP clients would agree on this. May I 
suggest that to be written a MAY instead?

In section 6.4 there's a typo:

    When the user agent generates an HTTP request for a particular URI,
    the user agent SHOULD attach exactly one HTTP named Cookie if the

insert 'header' after HTTP.

I don't understand the section saying:

    When generating a cookie-string from a URI with a "secure" scheme,
    the user agent MUST set the SECURE flag to true.  Otherwise, the user
    agent MUST set the SECURE flag to false.

What 'flag' is this referring to? This section is for sending the Cookie: 
header and I would presume stored received cookies already are marked secure 
or not. Similar wording is used later but then speaks of "the HTTP flag".

The section about the sorting of the cookie-list. Do implementations really 
bother about in which order the cookies are matched? I don't see how that is 
important (and again, I know an implementation that doesn't care).

The text about "Update the last-access field of each cookie" is certainly not 
a MUST but could be a useful suggestion. Still I think it could be left out 
entirely.

-- 

  / daniel.haxx.se