Re: [http-state] draft-ietf-httpstate-cookie-05 posted

[Adam Barth <[e-mail]>]

On Mon, Mar 15, 2010 at 12:37 PM, Paul E. Jones <[e-mail]> wrote:
> The rollover definitely occurs in 2038 if using a signed 32-bit integer to
> keep track of seconds since Jan 1, 1070.  However, I would recommend not
> inserting language like this into the spec, because it assumes a certain
> implementation.  Dates in the cookie spec themselves are not subject to this
> issue, after all.
>
> Didn't user agents already take this into consideration?  One could convert
> dates to a string format like "2010-03-15T19:32:00Z" or simply use a 64-bit
> integer similar to the Unix time_t type.  In any case, we should separate
> the protocol from implementation, and there's nothing preventing one from
> developing a user agent that handles the year 3054 if we so desired.  There
> will likely always be a maximum year supported by a user agent and, if the
> expiration date exceeds that year, I would assume that the user agent will
> apply the maximum expiration time it supports.

User agents are required to handle these cases gracefully.  The
language we're considering is a recommendation for servers to improve
interoperability with some existing user agents that don't handle this
case gracefully.

Adam