Re: [http-state] Is this an omission in the parser rules ofdraft-ietf-httpstate-cookie-21?
"Remy Lebeau" <remy@lebeausoftware.org> Wed, 16 February 2011 15:21 UTC
Return-Path: <SRS0=Ok7kSR=VN=lebeausoftware.org=remy@srs.bis.na.blackberry.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DB43A6E6A for <http-state@core3.amsl.com>; Wed, 16 Feb 2011 07:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.846
X-Spam-Level:
X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+X0tYDzbRBC for <http-state@core3.amsl.com>; Wed, 16 Feb 2011 07:21:33 -0800 (PST)
Received: from smtp21.bis.na.blackberry.com (smtp21.bis.na.blackberry.com [216.9.248.63]) by core3.amsl.com (Postfix) with ESMTP id 05CE53A6A25 for <http-state@ietf.org>; Wed, 16 Feb 2011 07:21:32 -0800 (PST)
Received: from bda933.bisx.prod.on.blackberry (bda933.bisx.prod.on.blackberry [172.20.220.96]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p1GFM0KB018978; Wed, 16 Feb 2011 15:22:00 GMT
Received: from bda933.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda933.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p1GFLx3o003924; Wed, 16 Feb 2011 15:21:59 GMT
X-rim-org-msg-ref-id: 1902806598
Message-ID: <1902806598-1297869719-cardhu_decombobulator_blackberry.rim.net-1954609536-@bda461.bisx.prod.on.blackberry>
Content-Transfer-Encoding: base64
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
To: Dan Winship <dan.winship@gmail.com>
From: Remy Lebeau <remy@lebeausoftware.org>
Date: Wed, 16 Feb 2011 15:21:59 +0000
Content-Type: text/plain
MIME-Version: 1.0
Cc: http-state@ietf.org
Subject: Re: [http-state] Is this an omission in the parser rules ofdraft-ietf-httpstate-cookie-21?
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: remy@lebeausoftware.org
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: Wed, 16 Feb 2011 15:22:48 -0000
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. ------Original Message------ From: Dan Winship To: Remy Lebeau Cc: ietf@adambarth.com Cc: http-state@ietf.org Subject: Re: [http-state] Is this an omission in the parser rules ofdraft-ietf-httpstate-cookie-21? Sent: Feb 16, 2011 5:30 AM On 02/16/2011 02:04 AM, Remy Lebeau wrote: > Since the cookie has a Version=1 attribute, it is an RFC 2109 cookie, > and RFC 2109 allows Netscape-style date/time formatting: > > Wdy, DD-Mon-YYYY HH:MM:SS GMT 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. -- Dan