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

Re: Comments on the new cookie draft

From: Dave Kristol <dmk@research.bell-labs.com>
Date: Fri, 21 Feb 97 11:12:24 EST
Message-Id: <9702211612.AA13056@zp>
To: yarong@microsoft.com
Cc: http-wg@cuckoo.hpl.hp.com
Yaron Goland <yarong@microsoft.com> wrote: 
  > The new cookie draft's backwards compatibility mechanism depends upon
  > the way that Netscape handles illegally formatted cookies, specifically
  > cookies with multiple NAME=VALUE pairs (where I use NAME=VALUE as given
  > >in http://home.netscape.com/newsref/std/cookie_spec.html). Netscape choose to

I disagree that these are "illegally formatted cookies".  (To be precise here,
we're talking about Set-Cookie headers, not Cookie headers or "cookies".)  We
are talking about Set-Cookie headers that contain unrecognized attribute-value
pairs.

  > >handle these illegal cookies by taking the first NAME=VALUE and making that
  > >the cookie's value. MSIE choose to handle these illegal cookies by taking the
  > >last NAME=VALUE. Neither implementation is wrong. As Netscape's many cookies
  > >drafts never specified how to handle illegally formatted cookies,
  > >implementers were free to do whatever they wanted. As such the current
  > >specification statement that "In other words, MSIE sends back the wrong
  > >cookie name and value." is factually incorrect, not to mention insulting.

I agree that there is no mention of how to handle unrecognized a-v
pairs.  I do not want to start a vendor-bashing session about who made
the better design choice for handling unrecognized a-v pairs.

In any case, I will adjust the "factually incorrect" wording.

  > >
  > >Given that no one wishes to implement a new cookie specification which will
  > >not work with a large segment of current browsers and given that no one
  > >wishes to make servers manipulate cookie field orderings based on the user
  > >agent, I would propose a solution which will be backwards compliant with all
  > >current browsers. We can use two cookie headers. Set-Cookie and
  > >Set-Cookie-V1. Set-Cookie will contain a normal V0 cookie. Set-Cookie-V1 will
  > >contain all fields shared w/V0, NAME=VALUE, domain, path, and secure.
  > >Set-Cookie-V1 will contain the new fields, version, comment and max-age.
  > >Furthermore Set-Cookie may also contain expires which will be ignored by any
  > >V1 compliant client. In addition we can actually drop the version field and
  > >simply increment the number in the header. In addition if a server knows it
  > >is talking with a V1 compliant client it can drop Set-Cookie all together and
  > >just return Set-Cookie-V1 with all relevant fields.

Almost a year ago we discussed introducing a new header for "new
cookies" but decided against it.  I believe the main reason we decided
against it was that servers would have to send both flavors for an
indeterminate length of time.  Or they would take the easy way out and
continue to send "old cookies", and we would never be able to accrue
the privacy and anti-spoofing benefits of "new cookies".

Dave Kristol
Received on Friday, 21 February 1997 08:15:52 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:30 EDT