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