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

From: Adam Barth <[email-masked]>
Date: Fri, 11 Dec 2009 14:41:55 -0800

Now that we're officially a working group, I propose that we adopt
draft-abarth-cookie-06 as working group item
draft-ietf-http-state-cookie:

http://www.ietf.org/id/draft-abarth-cookie-06.txt

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 12 Dec 2009 00:48:59 +0100 (CET)

On Fri, 11 Dec 2009, Adam Barth wrote:

> draft-abarth-cookie-06 as working group item draft-ietf-http-state-cookie:

+1

In general this is a pretty good spec now.

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.

... with no mention of exactly when the cookie's birth is. I figure we can 
define it to be since the receive moment for convenience if nothing else. 
Counting from the sending moment would be hard, even if I bet most server side 
implementations basically assumes it is from the moment they send the cookie. 
The difference should be miniscule in most cases.

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

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.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Fri, 11 Dec 2009 16:04:04 -0800

> In general this is a pretty good spec now.

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

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

> Is that a way to say that if the server violates the spec, so can the

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.

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 Dec 2009 19:19:41 -0700

> http://www.ietf.org/id/draft-abarth-cookie-06.txt

+1, this is a good start -- and reading the TODO items gives one a clear
sense of what needs to be added.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Barth <[email-masked]>
Date: Fri, 11 Dec 2009 20:45:46 -0800

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

I adapted some text from HTTPbis, which equivocates on this point:

[[
The Max-Age attribute indicates that
the cookie MUST NOT be returned to the server when its age is
greater than the specified number of seconds.
]]

In general, I'd like to align the spec with HTTPbis wherever possible.

> to read Section 5 to figure out what's going to happen.

Is this text clearer?

[[
NOTE: If the server supplies Set-Cookie headers that conform
to the grammar in this section, then the user agent will return a
Cookie header that conforms to the grammar above.  However, if the
user agent receives a Set-Cookie header that deviates from the
grammar in this section, the requirements in the next section might
cause the user agent to return a Cookie header that deviates from
the preceding grammar.
]]

> can iron out these issues.

I've added a TODO about this so we don't forget.

Adam

---

From: Dan Winship <[email-masked]>
Date: Sat, 12 Dec 2009 11:05:22 -0500

On 12/11/2009 06:48 PM, Daniel Stenberg wrote:
> ... with no mention of exactly when the cookie's birth is. I figure we
> can define it to be since the receive moment for convenience if nothing
> else. Counting from the sending moment would be hard, even if I bet most
> server side implementations basically assumes it is from the moment they
> send the cookie.

For the "max-age" Cache-Control directive, you count from the time in
the Date header. We could do the same (though we need to put something
about what to do if there's no Date header).

-- Dan

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 12 Dec 2009 19:57:37 +0100 (CET)

On Sat, 12 Dec 2009, Dan Winship wrote:

>> Counting from the sending moment would be hard, even if I bet most server 
>> side implementations basically assumes it is from the moment they send the 
>> cookie.
>
> For the "max-age" Cache-Control directive, you count from the time in the 
> Date header. We could do the same (though we need to put something about 
> what to do if there's no Date header).

I know the libcurl implementation simply takes the current time (when the 
cookie is parsed/handled by the client) and adds the cookie's given max-time, 
which thus matches the current draft. I would suspect others do too since it 
is the easiest approach.

Does anyone here know of an implementation that (tries to) make it based on 
the server-side's creation time?

-- 

  / daniel.haxx.se

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 12 Dec 2009 20:05:20 +0100

> about what to do if there's no Date header).

There is a difference between max-age in Cache-control and max-age in  
Set-Cookie: a response using max-age in Cache-Control can be cached for  
extensive periods before it is returned in response to a client request;  
that is unlikely to be the case for responses with Set-Cookie headers, and  
if it does happen, the time difference is unlikely to cause any major  
issues.

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: David Morris <[email-masked]>
Date: Sat, 12 Dec 2009 11:17:23 -0800 (PST)

> the server-side's creation time?

There is really no point in over engineering this value ... if it isn't
sufficient to expire the cookie max-age seconds from when it is parsed,
then max-age is fundamentally an inadequate mechanism for managing
expiration. Network delays, system processing delays, system time changes
all conspire to create imprecision. If a server can be subverted because a
cookie didn't expire for a few seconds longer than intended, of the user
experience is broken because it expired too soon, then there is an
underlying application design issue that no amount of hassling over
interpretation of the max-age value can resolve.

Simply stated, max-age is based on the receipt time of the response and
which shouldn't be any later than completion of processing the response 
or any earlier than when the request was made.

---

From: Dan Witte <[email-masked]>
Date: Mon, 14 Dec 2009 13:07:48 -0800 (PST)

Firefox does more than use client time. If the server time was provided via HTTP header, we calculate expiry times (for both "expires" and "max-age" attributes) relative to such time. If not, we use client time. (This code is encapsulated in http://mxr.mozilla.org/mozilla-central/source/netwerk/cookie/src/nsCookieService.cpp#2062.)

Regards,
Dan

----- Original Message -----
From: "Daniel Stenberg" <[email-masked]>
To: "Dan Winship" <[email-masked]>
Cc: "http-state" <[email-masked]>
Sent: Saturday, December 12, 2009 10:57:37 AM
Subject: Re: [http-state] Make draft-abarth-cookie-06 a working group item?

-- 

  / daniel.haxx.se
_______________________________________________
http-state mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/http-state

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 15 Dec 2009 00:33:39 +0100 (CET)

On Fri, 11 Dec 2009, Adam Barth wrote:

> Is this text clearer?
>
> NOTE: If the server supplies Set-Cookie headers that conform to the grammar 
> in this section, then the user agent will return a Cookie header that 
> conforms to the grammar above.  However, if the user agent receives a 
> Set-Cookie header that deviates from the grammar in this section, the 
> requirements in the next section might cause the user agent to return a 
> Cookie header that deviates from the preceding grammar.

They way I read this is still like this:

If a server violates the spec and sends something that isn't a valid cookie, 
the server should expect that the client *too* may violate the spec and send 
something non-conformant back.

... and I have trouble accepting that we include in the spec that server may 
or will violate the spec and it even seems to say that a client is then fine 
to accept such illegal cookies and continue as if they were valid and even 
send them back in subsequent requests!

Invalid headers are wrong, they should be treated as protocol errors and the 
world will be a much better place if clients IGNORE such cookies instead of 
trying hard to obey.

If invalid headers are so common that we need to document them especially, 
then we must change the spec so that they are in fact valid instead as we are 
here to document existing practises and not an imaginary protocol that isn't 
in fact used by most implementations.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Tue, 15 Dec 2009 11:41:10 -0800

> Firefox does more than use client time. If the server time was provided via HTTP header, we calculate expiry times (for both "expires" and "max-age" attributes) relative to such time. If not, we us…

Thanks.  I've added this to the draft.  I don't have a good way to
test this yet, but I'll figure that.

Adam