Re: [http-state] Is this an omission in the parser rules of draft-ietf-httpstate-cookie-21?

"Remy Lebeau" <> Thu, 17 February 2011 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 334213A6D26 for <>; Thu, 17 Feb 2011 11:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6WSG2o38ajbY for <>; Thu, 17 Feb 2011 11:45:52 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 4BC113A6D5E for <>; Thu, 17 Feb 2011 11:45:52 -0800 (PST)
Received: (qmail 8265 invoked from network); 17 Feb 2011 19:46:22 -0000
Received: from unknown ( by ( with ESMTP; 17 Feb 2011 19:46:22 -0000
Message-ID: <D6C8DF74A2A54926A2663B804984F9C7@RYANLAPTOP>
From: "Remy Lebeau" <>
To: "Dan Winship" <>
References: <><><><><><> <> <26A4B40A07EF489C882815971D7BC38E@RYANLAPTOP> <>
Date: Thu, 17 Feb 2011 11:45:55 -0800
Organization: Lebeau Software
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Subject: Re: [http-state] Is this an omission in the parser rules of draft-ietf-httpstate-cookie-21?
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: Thu, 17 Feb 2011 19:45:53 -0000

(Not sure if this got posted correctly, so re-posting)

----- Original Message ----- 
From: "Dan Winship" <>
To: "Remy Lebeau" <>
Cc: <>om>; <>
Sent: Wednesday, February 16, 2011 5:30 AM
Subject: Re: [http-state] Is this an omission in the parser rules 

> Not that any of this is in any way relevant, but, no it doesn't. RFC
> 2109 doesn't allow the Expires attribute at all. A cookie that contains
> both "Version=1" and "Expires=..." does not conform to *any* spec.

Expires was not in the RFC 2109 grammar for the Set-Cookie header, but most 
implementations did not use Max-Age. The draft allows user agents to support 
both from a server, and RFC 2109 Section 10.1.2 told user agents to 
recognize Expires if present:

10.1.2  Expires and Max-Age

   Netscape's original proposal defined an Expires header that took a date 
value in a fixed-length variant format in place of Max-Age:

   Wdy, DD-Mon-YY HH:MM:SS GMT

   Note that the Expires date format contains embedded spaces, and that 
"old" cookies did not have quotes around values.  Clients that implement to 
this specification should be aware of "old" cookies and Expires.

The wording of that last sentence does not suggest to me, at least, that the 
presence of Expires is strictly dependant on an "old" cookie being used. And 
we can see in real-world cookies that Netscape-style Expires are commonly 
used in RFC-style cookies from servers.