- 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