RE: Comments on the new cookie draft

>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.

Netscape's drafts allowed for ONE unrecognized attribute-value pair.
This unrecognized attribute-value pair was to be the value of the
cookie. Therefore a cookie with multiple unrecognized attribute-value
pairs is illegal and an implementer is free to handle them anyway they
want to. A draft which depends upon how implementers handle an illegal
situation for which the specifications provided no guidance is, IMHO,
broken.

>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".

Alas this is the fortune reaped by the wide spread acceptance of a
proprietary standard. At least with two headers the load on server
processing is reduced versus having to sniff for UAs in order to
determine how to format the cookie. Given that the crux of the issue is
the server vendor's needs, it would seem appropriate for them to
comment. Would they rather sniff UA strings to determine how to properly
format their cookies or would they rather be able to always send out two
headers and know things will work?

		Yaron

>-----Original Message-----
>From:	dmk@research.bell-labs.com [SMTP:dmk@research.bell-labs.com]
>Sent:	Friday, February 21, 1997 8:12 AM
>To:	Yaron Goland
>Cc:	http-wg@cuckoo.hpl.hp.com
>Subject:	Re: Comments on the new cookie draft
>
>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 11:25:54 UTC