RE: The state of cookies

In general I do not believe that the two value solution is feasible
because of the extra overhead it would incur. Many systems are becoming
more and more reliant upon cookies for state information and thus are
increasing the size of their cookies. Any backwards compatible solution
must not require the repetition of the name/value headers.

My proposal to deal w/this situation is to introduce a two header
approach. The definition of set-cookie2 is as given in David Kristol's
latest draft but with a few additions. A set-cookie header may be sent
but only if the fields are separated by ";" (not ","). We would also
officially define the expires attribute in Dave's spec, as given in the
Netscape spec, but declare it deprecated. So it is legal to include an
expires attribute. We would also declare that if a cookie contains both
an expires and max-age attribute, then the expires attribute is ignored.
Furthermore only headers defined in Netscape's original draft may be
placed in the set-cookie header. As this means there will be only a
single "unknown" name/value pair, the cookie will work with all cookie
compliant browsers. The set-cookie2 header would then contain any
additional headers, such as version, comment, and max-age, that are not
defined in the Netscape spec and thus can not be sent in set-cookie.
Older clients will only see set-cookie and everything will work just
fine. New clients will combine the set-cookie and set-cookie2 headers,
with max-age overriding expires, and will also have the proper behavior.
The only redundancy is the expires and max-age fields which are usually
smaller than the name/value fields.

Multiple headers are dealt with by matching set-cookie and set-cookie2
in relative ordering. So if I take all the set-cookie headers in a
document and combine them together I get a single set-cookie header
defined as "set-cookie: A1, A2, A3, ....,An", where AX represents a
cookie. Combining all the set-cookie2 headers together in a response
results in "set-cookies2: B1, B2, B3,...,Bn". Now match the cookies by
number so the final cookies will be "set-cookie: A1B1, A2B2, A3B3, ...,
AnBn". As HTTP guarantees the relative ordering of headers, the result
will always be deterministic.

			Yaron


>-----Original Message-----
>From:	Jeffrey Mogul [SMTP:mogul@pa.dec.com]
>Sent:	Tuesday, March 04, 1997 10:29 AM
>To:	http-wg@cuckoo.hpl.hp.com
>Subject:	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 21:57:16 UTC