- From: Dave Kristol <dmk@research.bell-labs.com>
- Date: Mon, 3 Mar 97 10:35:52 EST
- To: masinter@parc.xerox.com
- Cc: http-wg@cuckoo.hpl.hp.com
Larry Masinter <masinter@parc.xerox.com> wrote:
> Can someone please write a short, self-contained
> description of what in RFC 2109 is technically "broken"?
> Why it is that vendors can't just implement the "proposed
> standard" as a hotfix or patch or in their next release?
See draft-ietf-http-state-mgmt-errata-00.txt. The relevant section
[edited by me for this email] says:
Microsoft Internet Explorer (MSIE) Version 3 and earlier will
fail to handle some cookies that use this specification. For
example, if a server sends the following response header to MSIE V3
(omitting the line breaks):
Set-cookie: xx="1=2&3-4";
Comment="blah";
Version=1; Max-Age=15552000; Path=/;
Expires=Sun, 27 Apr 1997 01:16:23 GMT
then MSIE V3 will send something like the following request header
next time:
Cookie: Max-Age=15552000
instead of [what Netscape's implementation would have returned]:
Cookie: xx="1=2&3-4"
What is at issue is what happens when the user agent gets a Set-Cookie
response header that contains more than one unrecognized attribute.
(The cookie value always looks like an unrecognized attribute.) RFC
2109 defines new attributes Comment, Max-Age and Version. I'm guessing
that Netscape assumed the first a-v was always the cookie value. MSIE
appears to treat the value for the *last* unrecognized attribute as the
cookie value. Thus, MSIE will interpret *every* new cookie differently
from Netscape, because there will always be at least a Version attribute
that MSIE won't recognize (and will treat as the cookie value).
Certainly a fix is possible, but you can't have much assurance that all
MSIE users will pick it up and install it. Without the fix, MSIE will
not return the cookie name/value for V1 cookies that servers expect.
Dave Kristol
Received on Monday, 3 March 1997 08:09:02 UTC