[http-state] cookie server conformance
Peter Saint-Andre <stpeter@stpeter.im> Thu, 27 January 2011 02:40 UTC
Return-Path: <stpeter@stpeter.im>
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 6BFDE3A6906 for <http-state@core3.amsl.com>; Wed, 26 Jan 2011 18:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level:
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 pi8nAm88rv62 for <http-state@core3.amsl.com>; Wed, 26 Jan 2011 18:40:47 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 316323A6898 for <http-state@ietf.org>; Wed, 26 Jan 2011 18:40:47 -0800 (PST)
Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 095EF400F6; Wed, 26 Jan 2011 20:00:05 -0700 (MST)
Message-ID: <4D40DBD3.6070603@stpeter.im>
Date: Wed, 26 Jan 2011 19:43:31 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Discuss HTTP State Management Mechanism <http-state@ietf.org>, Robert Sparks <rjsparks@nostrum.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms060903000909060505040400"
Subject: [http-state] cookie server conformance
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: Thu, 27 Jan 2011 02:40:48 -0000
During IESG review, Robert Sparks posted the following DISCUSS regarding draft-ietf-httpstate-cookie: In 4.1.1 (Syntax) - Why is the specification part of this proposed standard allowing implementations to violate the grammar defined by this standard? The SHOULD NOT in the first paragraph of this section must be a MUST NOT. If the intent is to make sure clients are liberal in what they accept because existing servers may generate non-conformant grammar, just say that (and if possible, point to what they might need to expect). If the intent is to allow servers that are compliant to generate messages not covered by this grammar, then the grammar is incorrect. If that's the case, the grammar should be extended to allow the alternate behavior and the document's prose can say that servers SHOULD NOT use those parts of the grammar. We've had some discussion between Robert, Adam, Jeff, and me to clarify Robert's concerns. In essence, Robert is concerned that it's merely implicit that a compliant server MUST NOT generate cookies that don't conform to the well-behaved profile defined in Section 4. He derives this conclusion from two pieces of evidence... First, Section 1 of verson -21 states: To maximize interoperability with user agents, servers SHOULD limit themselves to the well-behaved profile defined in Section 4 when generating cookies. Second, Section 4 states: Servers SHOULD NOT send Set-Cookie headers that fail to conform to the following grammar: Therefore, we can conclude that if a server sends a Set-Cookie header that violates the grammar, then it is non-conforming. However, we don't come right out and say that. To address Robert's concern and to make the constraints more explicit (it's often problematic to let such things remain implicit), in the off-list thread with Robert I formulated some proposed text, which I'd like to share with the working group... First, I proposed that we could modify Section 1 as follows: Compliant servers MUST limit themselves to the well-behaved profile defined in Section 4 when generating cookies. Second, I proposed that we could then simplify Section 4 as follows: This section describes the syntax and semantics of a well-behaved profile of the Cookie and Set-Cookie headers. I think that's a bit cleaner because it's not subject to as much interpretation. However, the change from SHOULD to MUST is not insignificant, so I think it's something that the working group needs to discuss. Your feedback is welcome. Peter -- Peter Saint-Andre https://stpeter.im/
- [http-state] cookie server conformance Peter Saint-Andre
- Re: [http-state] cookie server conformance Daniel Stenberg
- Re: [http-state] cookie server conformance =JeffH