[http-state] Parsing the Date header (was Re: Ticket 6: host-only cookies)

Adam Barth <ietf@adambarth.com> Fri, 29 January 2010 18:11 UTC

Return-Path: <adam@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 131273A6941 for <http-state@core3.amsl.com>; Fri, 29 Jan 2010 10:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.802
X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id LdGAv+KBF3Eq for <http-state@core3.amsl.com>; Fri, 29 Jan 2010 10:11:39 -0800 (PST)
Received: from mail-px0-f186.google.com (mail-px0-f186.google.com []) by core3.amsl.com (Postfix) with ESMTP id A0ACD3A6819 for <http-state@ietf.org>; Fri, 29 Jan 2010 10:11:39 -0800 (PST)
Received: by pxi16 with SMTP id 16so2085842pxi.29 for <http-state@ietf.org>; Fri, 29 Jan 2010 10:11:59 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id 40mr796316wfa.51.1264788717477; Fri, 29 Jan 2010 10:11:57 -0800 (PST)
From: Adam Barth <ietf@adambarth.com>
Date: Fri, 29 Jan 2010 10:11:37 -0800
Message-ID: <7789133a1001291011h39f90345j6c9339849adc3542@mail.gmail.com>
To: Dan Winship <dan.winship@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: http-state <http-state@ietf.org>
Subject: [http-state] Parsing the Date header (was Re: Ticket 6: host-only cookies)
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: Fri, 29 Jan 2010 18:11:41 -0000

On Fri, Jan 29, 2010 at 6:23 AM, Dan Winship <dan.winship@gmail.com> wrote:
> On 01/29/2010 03:38 AM, Adam Barth wrote:
>> There's also a minor point about parsing the Date header:
>> [[
>> Let server-date be the date obtained by parsing the contents of
>> the last Date header field as a cookie-date.
>> ]]
>> http://tools.ietf.org/html/draft-ietf-httpstate-cookie-02#section-5.2.2
>> I'm not sure whether that's a big deal though.
> 2616 and httpbis both say:
>      Note: Recipients of date values are encouraged to be robust in
>      accepting date values that may have been sent by non-HTTP
>      applications
> So, you're ok.
> Though I'm not convinced the text is needed; the Date header is most
> likely generated by a lower-level part of the server stack that was
> written by people who are actually aware of the relevant specs. When I
> was logging my cookie traffic a few years ago, despite all the
> variations I found in cookie Expires attributes, I only found a single
> non-rfc1123 Date header, and that was from a guy who had written his own
> http server. (And he'd actually already noticed that bug and fixed it,
> but not yet deployed the fixed version yet.)

That's an interesting data point.  I'm happy to refer to HTTP for
interpreting the Date header if we don't need the wacky cookie-date
parser for compatibility.

One subtly is that part of the reason with have this date arithmetic
is to compensate for servers that have large clock skew or use non-GMT
timezones.  In particular, the cookie-date parser ignores any timezone
decorations.  We want to make sure whatever parser we use for the Date
header does the same thing so that when we subtract them we get the
"right" relative time.