Comments on the new cookie draft

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

Received on Thursday, 20 February 1997 16:29:23 UTC