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

["Yngve Nysaeter Pettersen" <[e-mail]>]

On Mon, 15 Mar 2010 23:10:20 +0100, Adam Barth <[e-mail]> wrote:

> Yngve, was your recommendation motivated by the behavior of any
> particular user agent?

No.

However, I've just confirmed that many of compilers for the device  
(non-desktop) platforms we are delivering on are using a 32 bit time_t.

At the very least this could indicate that other clients are also limited
by 32 bit, and might using conversion functions that return an error value
instead of an upper limit date when the year is outside the allowed range.
At best this could mean that the cookie is converted to a session cookie.

Opera is currently enforcing an upper limit of 2036 for dates on the form
used for Expires (I have filed a bug on that). There is no such limit for
max-age, except the max value that can be represented.

I wonder if the Expires/Max-age should discourage using values more than a
few years into the future. One thing is that it is unlikely that the
client will exist as long (but that to the end of client existence aspect
is probably what the designer want); another is that the server will have
to maintain a database for those sessions for a very long time, possibly
leading to a lot of storage overhead; a third is that quite a few people
frown upon the use of long-lasting cookies. Maybe a recommendation of "not
more than" 2 or 3 years should be added as a best-practice?

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************