Re: [http-state] Updated draft

[Adam Barth <[e-mail]>]

On Sat, Aug 15, 2009 at 2:06 PM, Daniel Stenberg<[e-mail]> wrote:
> 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.

Yes.  I've added a TODO to move this to one of the conformance sections.

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

Done.  I have it on good authority that there exist sites that break
if you change this number.  However, I've softened the draft to make
50 only a suggestion.

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

Fixed.

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

Yeah, this is pretty clumsy.  I was trying to make the cooke selection
algorithm simpler, but it didn't work out well.  I've added a TODO to
fix this.

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

Yes.  The bit about sorting by path length is definitely required for
compatibility.  I remember reading some old bug reports about that.  I
suspect the bit about creation date is important too, although I don't
have concrete examples of sites that break.  I don't have a test case
written for the sorting yet, but I believe IE, Firefox, and Chrome do
this.  I haven't tested Safari or Opera.

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

That's the only text that gives semantics to the last-access field,
which is needed during eviction.

Adam