Re: [http-state] cookie-date syntax and algorithm

Adam Barth <> Fri, 22 January 2010 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5464A3A6A76 for <>; Fri, 22 Jan 2010 09:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y1f+PmA5SBLn for <>; Fri, 22 Jan 2010 09:33:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 67A5228C10C for <>; Fri, 22 Jan 2010 09:33:41 -0800 (PST)
Received: by pwi20 with SMTP id 20so967802pwi.29 for <>; Fri, 22 Jan 2010 09:33:33 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id w40mr2143826wfh.344.1264181611147; Fri, 22 Jan 2010 09:33:31 -0800 (PST)
In-Reply-To: <>
References: <>
From: Adam Barth <>
Date: Fri, 22 Jan 2010 09:33:11 -0800
Message-ID: <>
To: "NARUSE, Yui" <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [http-state] cookie-date syntax and algorithm
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: Fri, 22 Jan 2010 17:33:42 -0000

On Fri, Jan 22, 2010 at 9:07 AM, NARUSE, Yui <> wrote:
> I sent this from but it seems not accepted,
> so I post this again.
> Anyway,
> draft-ietf-httpstate-cookie-02 says in 4.1.1. Syntax,
>   cookie-date       = <rfc1123-date, as defined in RFC 2616>
> But you know, cookie-date is not rfc1123-date.
> It's a original exotic date format.
>   rfc1123-date = <Wdy, DD Mon YYYY HH:MM:SS GMT>
>   rfc850-date  = <Weekday, DD-Mon-YYYY HH:MM:SS GMT>
>   asctime-date = <Wdy, Month dd HH:MM:SS YYYY>
>   cookie-date  = <Wdy, DD-Mon-YYYY HH:MM:SS GMT> ; not RFC 2822
> Current description causes misunderstanding.

If you read the requirements in Section 4.1.1, you'll see that we
recommend (but do not require) servers use this syntax.  User agents
are required to process the exotic format.

> = 5.1.1.  Dates
> Why it needs such a complex definition?

This complex definition is required so that user agents can
interoperate with servers that send dates in exotic formats.

> Its demerit is clear in ticket #7.

Ticket 7 is about testing.  We're aiming to test everything in the spec.

> It seems to intend to change cookie-date from current exotic format
> to exact rfc-1123-date or something in future, but why?

We're recommending that servers use a sane date format even though
user agents are required to process insane date formats.  This advice
appears sound to me.

> Recently, many specs are using ISO 8601 Date and Time format (or other
> related specs).
> So formats they really needed are only exotic and ISO 8601.
> Current algorithm make things too complex but still can't express timezone.
> So I object this.

As distasteful as we might find the exotic date format, it's a sad
reality that user agents encounter insane dates on a regular bases.
Unlike some of the other instances where I push for precise error
handling, in this case, we have ample examples of servers sending
insane dates.  To wit:

To respond to your statement with a finer point: user agents who use
ISO 8601 dates will be unable to interoperate with a large number of
servers.  Therefore, the ISO 8601 dates are unacceptable for our
purpose here.