[http-state] 32 bit dates and 2038

Adam Barth <ietf@adambarth.com> Thu, 08 April 2010 00:11 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id EDC5C3A6853 for <http-state@core3.amsl.com>; Wed, 7 Apr 2010 17:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.53
X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id q9ZEpe8YmIkj for <http-state@core3.amsl.com>; Wed, 7 Apr 2010 17:11:17 -0700 (PDT)
Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com []) by core3.amsl.com (Postfix) with ESMTP id 493023A6842 for <http-state@ietf.org>; Wed, 7 Apr 2010 17:11:17 -0700 (PDT)
Received: by yxe9 with SMTP id 9so883611yxe.29 for <http-state@ietf.org>; Wed, 07 Apr 2010 17:11:09 -0700 (PDT)
Received: by with SMTP id v9mr4055235ybm.346.1270685469199; Wed, 07 Apr 2010 17:11:09 -0700 (PDT)
Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com []) by mx.google.com with ESMTPS id 20sm6473335iwn.9.2010. (version=SSLv3 cipher=RC4-MD5); Wed, 07 Apr 2010 17:11:08 -0700 (PDT)
Received: by iwn27 with SMTP id 27so1072814iwn.5 for <http-state@ietf.org>; Wed, 07 Apr 2010 17:11:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 7 Apr 2010 17:10:46 -0700 (PDT)
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 7 Apr 2010 17:10:46 -0700
Received: by with SMTP id l18mr4375468ibv.74.1270685467295; Wed, 07 Apr 2010 17:11:07 -0700 (PDT)
Message-ID: <k2w5c4444771004071710y87a7380bl9efc2f7d416b6800@mail.gmail.com>
To: http-state <http-state@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Daniel Stenberg <daniel@haxx.se>
Subject: [http-state] 32 bit dates and 2038
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 00:11:19 -0000

Thanks for all your feedback about 32-bit date representations.
Here's the text I went with.

          <t>NOTE: Some user agents represent dates using 32-bit integers.
          Some of these user agents might contain bugs that cause them process
          dates after the year 2038 incorrectly. Servers wishing to
          interoperate with these user agents might wish to use dates before

Detailed responses below.


On Thu, Mar 11, 2010 at 2:05 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> On Wed, 10 Mar 2010, Adam Barth wrote:
>>         <t>To maximize compatibility with user agents, servers SHOULD use
>>         sane-cookie-dates before 2036 due to 32-bit "time_t" rollover.
>>         Hopefully the industry will resolve this issue in some way as 2036
>>         approaches.</t>
> Did you actually mean 2038 or is there any particular reason why there's a
> margin? See http://en.wikipedia.org/wiki/Year_2038_problem

Oops.  Yes.  2038.

On Mon, Mar 15, 2010 at 10:17 AM, David Morris <dwm@xpasc.com> wrote:
> On Mon, 15 Mar 2010, Adam Barth wrote:
>> On Mon, Mar 15, 2010 at 9:14 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> > It has been reserved, should be reserved, and seems to be only used *very*
>> > rarely...
>> We're only supposed to require user agents to do things that are
>> already widely implemented.  I'll happily add this requirement if user
>> agents widely implement it, but that's not the case currently.
>> There's a bunch of stuff in RFC 2109 that's been "reserved" and
>> "should be reserved" but the reality today is that it isn't reserved.
> I interpret 'reserved' as an advisory term ... it doesn't place any new
> requirement on User Agents but does warn the world that use is not
> considered appropriate. Since it is apparently know who some of the
> design firms are, it might be a good approach to informally remind
> them of the reserved status.
> Since the actual use is server controlled, it doesn't seem unreasonable
> to expect a change could be implemented over the many months between when
> this work is published as an RFC and when the first browser update
> might decide to enforce the reservation... perhaps as an invalid cookie
> warning popup?

I think "invalid cookie" popups are probably out of the question for
many user agents.

On Mon, Mar 15, 2010 at 4:57 PM, Paul E. Jones <paulej@packetizer.com> wrote:
>> > there are only a small handful of browsers that need to handle those
>> > cookies.
>> I'm claiming that statement is wrong.
>> Cookies are handled client-side by HTTP clients that handle cookies.
>> There are
>> far more such client implementations in wide use than "just" the major
>> browsers, like for example the library I myself work with: libcurl. But
>> there
>> are a large number of other implementations of tools and libraries
>> handling
>> cookies that are used out there.
>> Most probably not at all as many as the server-side apps creating the
>> cookies,
>> but certainly not limited to "a small handful of browsers".
> Ah, yes... I understand your point now, and you're right.
> However, the fact you're engaged in this draft speaks to the point I tried
> to make: those building UAs are likely going to read this spec.  I would
> venture to guess there will be thousands of application developers
> generating cookies that never read this spec.

Indeed.  That's why we have much more precise guidance for user agents
than we do for servers.  In any case, however, it seems useful to give
advice to those server operators who will end up reading the spec.

On Tue, Mar 16, 2010 at 7:14 AM, Yngve Nysaeter Pettersen
<yngve@opera.com> wrote:
> On Mon, 15 Mar 2010 23:10:20 +0100, Adam Barth <ietf@adambarth.com> 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.

Thanks.  I've taken your advice on this point.

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

We could add such advice, but I haven't at this point.  I think these
considerations hold true in browser usage scenarios, but other usage
scenarios might be different.  For example, imagine a user agent that
talks only to a single server (e.g., because it's a bot).  In that
case, the server can happily use long-lasting cookies without fear of

On Tue, Mar 16, 2010 at 10:20 AM, Paul E. Jones <paulej@packetizer.com> wrote:
> I think that's a reasonable recommendation, since such cookies waste space
> and might be viewed as a privacy concern by some.  We've seen stories about
> user outcry over long-lived "tracking" cookies and such.  Perhaps we might
> even go a step further and say that the UA may reduce the expiration time as
> it sees fit.

The spec does allow user agents to reduce the expiration time as they see fit.