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

[David Morris <[e-mail]>]

On Sat, 12 Dec 2009, Daniel Stenberg wrote:

> On Sat, 12 Dec 2009, Dan Winship 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).
>
> 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?

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.