W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1997

Re: new prospective cookie draft

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Mon, 17 Feb 1997 20:37:03 -0500 (EST)
To: dmk@research.bell-labs.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2413
dmk@research.bell-labs.com (Dave Kristol) wrote:
>I've created a cookie draft that merges state-mgmt-05 and
>state-mgmt-errata-00 plus subsequent comments.  Please look it over.
>You can get to it from
>http://portal.research.bell-labs.com/~dmk/cookie-ver.html .
>If there are no violent objections, I will submit it as state-mgmt-06
>on Wednesday with the goal of slipping it into the RFC Editor's pile in
>place of state-mgmt-05, which has not yet made RFC status.  I contend
>the changes are purely editorial and add clarification.

	(1) In section 10.3 concerning compatibility with MicroSoft's
implementation, the wording implies that this is a "proper" Version
1 Set-Cookie header:

Set-cookie: xx="1=2&3-4";
    Version=1; Max-Age=15552000; Path=/;
    Expires=Sun, 27 Apr 1997 01:16:23 GMT

which MicroSoft's parser mishandles by sending:

    Cookie: Max-Age=15552000

instead of the "correct"

    Cookie: xx="1=2&3-4"

	"Expires" is not one of the attribute names for Version 1
cookies.  Thus, isn't it a valid cookie name, and isn't it's presence
in a Set-cookie header that claims to be Version 1 but expects it to
be handled as a Version 0 Expires attribute invalid?  Also, skipping
that Expires ambiguity, isn't this what's "correct":

    Cookie: $Version=1; xx="1=2&3-4"; $Path=/; $Domain=foo.blah.dom

	(2) Re Section 10.2 concerning compatibility with Netscape's
original cookie implementation (Version 0), when initially implementing
the draft for Lynx v2.7, we interpreted it to be saying that in the
absence of a version parameter, the $Version= should not be prepended,
but the ; $Path=  and  ; $Domain=  still should.  That didn't work out
at all.  For example, if you try that with the www.research.digital.com
test service, it treats everything following the testcookie= as the
value (i.e., doesn't trim on the semi-colon), and reports a bad
value.  Looks like CyberDog initially implemented it that way and
similarly got false errors from that service.  I realize one could
say, "We'll, people should fix their parsers.", but in the real world
we didn't find a single case of proper parsing for Version 0 cookies,
and ended up dropping the use of $Path and $Domain unless the Set-Cookie
header includes a version=[ >= 1 ].  You might want to take that field
experience into account, or perhaps we misinterpreted the recommendation.


 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
Received on Monday, 17 February 1997 17:44:01 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:01 UTC