Re: The state of cookies

I'm not all that much of a Cookie fanatic, and I've been busy enough
with other stuff that I've let most of the Cookie debate slide past
unread.  But Dave Kristol's summary of the problem caught my
attention:

    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).
    
In other words, if you send this,

     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 Netscape will get the right result, and MSIE will get the wrong
one.  And if you send this

     Set-cookie: Comment="blah";
         Version=1; Max-Age=15552000; Path=/;
         Expires=Sun, 27 Apr 1997 01:16:23 GMT; xx="1=2&3-4"

then MSIE will get the right result, and Netscape will get the wrong
one.  Right?

It seems to (naive) me that there is at least one workaround to this
problem, that does NOT require propagating a fix to the installed
base of browsers:  Send the cookie value twice.

E.g., if the server sends

     Set-cookie: xx="1=2&3-4";
         Comment="blah";
         Version=1; Max-Age=15552000; Path=/;
         Expires=Sun, 27 Apr 1997 01:16:23 GMT;
	 xx="1=2&3-4"

then won't the right thing with both Netscape and MSIE?  (This is,
of course, assuming that there isn't a third interpretation of the
old-cookie technique floating around in a lot of browsers.)

The current state-management RFC says:
   If an attribute appears more than once in a
   cookie, the behavior is undefined.

But I think you could fix that by saying "unless the value
is the same in each appearance, in which case subsequent
appearances are no-ops."

True, this sends more bits over the wire ... but it does
seem to solve the downwards compatibility problem.  And
if the origin server knows that the user-agent is compliant
with the new cookie spec (sorry, I won't speculate on the
techniques for learning that!) then this should go away
after a while.

I described this approach to Dave Kristol, who thought it
"may possibly work", and pointed out this problem:

    The first problem that comes to mind is the size limit on a
    cookie.  If the cookie value is real long (many characters), having
    two of them may put the Set-Cookie header over the limit.  I don't
    think you can finesse that one by saying "don't count the second
    copy", because I suspect there are 4K buffers in browsers for
    headers.

I don't know if (in effect) halving the size of the Cookie value
would be a serious practical limitation or not.  I looked at the
cookie file my own browser has been keeping, and the largest one
there was about 900 bytes.

Anyway, since I don't really care that much about cookies, and
I have too many other controversial views to defend, I'm not
going to try to defend this one (so don't worry about calling
it stupid).

-Jeff

Received on Tuesday, 4 March 1997 10:34:45 UTC