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

"Yngve Nysaeter Pettersen" <> Tue, 16 March 2010 14:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A1623A6984 for <>; Tue, 16 Mar 2010 07:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.111
X-Spam-Status: No, score=-5.111 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JoqUkIy9fFvX for <>; Tue, 16 Mar 2010 07:14:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B40713A6941 for <>; Tue, 16 Mar 2010 07:14:14 -0700 (PDT)
Received: from killashandra.oslo.osa ( []) by (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o2GEDwF9006544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Mar 2010 14:14:04 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Organization: Opera Software
References: <> <op.u9dpzpdoqrq7tp@acorna> <> <> <op.u9feulgkqrq7tp@acorna> <009401cac476$eb8c83c0$c2a58b40$@com> <> <009a01cac489$47f0fda0$d7d2f8e0$@com> <>
To: "Paul E. Jones" <>, "Adam Barth" <>
Date: Tue, 16 Mar 2010 15:14:09 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve Nysaeter Pettersen" <>
Message-ID: <op.u9ny5vnavqd7e2@killashandra.oslo.osa>
In-Reply-To: <>
User-Agent: Opera Mail/10.50 (Win32)
Cc: Daniel Stenberg <>, http-state <>
Subject: Re: [http-state] draft-ietf-httpstate-cookie-05 posted
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Mar 2010 14:14:33 -0000

On Mon, 15 Mar 2010 23:10:20 +0100, Adam Barth <> wrote:

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


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?

Yngve N. Pettersen
Senior Developer		     Email:
Opera Software ASA         
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01