Re: [http-state] Make draft-abarth-cookie-06 a working group item?

[Adam Barth <[e-mail]>]

On Fri, Dec 11, 2009 at 3:48 PM, Daniel Stenberg <[e-mail]> wrote:
> In general this is a pretty good spec now.

Thanks.  There's a lot still left to do through.  :)

> Here's some additional random thoughts on the current version:
>
> Max-age is now specified to be:
>
>      The value of the Max-Age attribute represents the maximum
>      lifetime of the cookie, measured in seconds from the moment the
>      user agent receives the cookie
>
> RFC2109 and 2965 that both include max-age defined Max-age to be:
>
>      The Max-Age attribute defines the lifetime of the cookie, in seconds.

I'm happy to use the RFC2109 and 2965 working if you think that's clearer.

> I have some problems with this phrase in 4.2.1:
>
>   NOTE: If the server supplies a Set-Cookie header that does not
>   conform to the grammar in Section [TODO], the user agent might not
>   supply a Cookie header that conforms to the preceding grammar.
>
> Is that a way to say that if the server violates the spec, so can the
> client?

I need to make this clearer.  What this means is if the server
includes a funny character in a cookie name (like +) that is outside
the grammar, then the client will return that value even though it
doesn't conform to the grammar.

> I don't see any reason to A) offer the client a way to not adhere to
> the spec and B) imply that the client would deal with improplerly formatted
> cookies in any particular way that isn't even following this spec! But of
> course, I'm not sure what the [TODO] is so I might have misunderstood this
> paragraph.

The intent is as follows:

1) A user agent should always follow the rules in Section 5.
2) If the server follows the rules in Section 4, then everything is
nice and sane and works as described in Section 4.
3) If the server doesn't follow the rules in Section 4, then you need
to read Section 5 to figure out what's going to happen.

> And for the sake of it, I'll maintain that I am against section 5.3 rule
> number 2. I argue that both those cookie sort order keys are not a MUST. I
> just cannot agree with that.

Keep in mind that this draft is just the starting point for
discussion.  I expect there will be many more drafts to come where we
can iron out these issues.

Adam