Re: Set-Cookie2: "additive" vs. "independent"

dmk@research.bell-labs.com (Dave Kristol) wrote:
>[...]
>The one rub is how to handle gracefully a transition from old-style
>("Netscape") cookies to new-style cookies.  The scenario I just described
>above locks the dialog into either old- or new-style cookies, because the
>server only sends one header, either Set-Cookie or Set-Cookie2.  What if
>the user upgrades the UA to one that understands new-style cookies, but the
>current cookie dialogs it engages in use old-style cookies?  We would like
>the UA and server to begin exchanging new-style cookies.  But neither side
>knows that the other understands new-style cookies.  Who goes first to make
>their capabilities known?
>
>I can think of two approaches, and I'm sure there are others.  One approach
>is just to have the server periodically send both Set-Cookie and
>Set-Cookie2 as a probe.  The cookie value might, for example contain the
>timestamp of the last contact with the server, and the server could send
>both headers once each day/week/whatever.
>
>Simpler still, a UA that supports new-style cookies should be sending
>	Cookie: $Version=0
>followed by other cookie values.  If the server understands new-style
>cookies, it could respond to further requests with Set-Cookie2.

	I just tried sending  Cookie: $Version=0; realcookie=realvalue
for:

   Linkname: HTML Form-Testing Home Page
        URL: http://www.research.digital.com/nsl/formtest/home.html

and got back:
                        Form Test Results for General1
                                       
   Test results:
     * NetscapeCookie - Bad HTTP Cookie value: $Version=0; COOKIE=testvalue
[...]


	The problem is that you're counting on $Version=0; being treated
as a bad cookie by the old server or script, and don't know what error
handling it's using.  It indeed would be desireable for the UA to
communicate that it supports version 1 or greater cookie handling in
those cases for which it is using cached version 0 cookies and doesn't
yet know if the server or script can handle new cookies.  The simplest,
most efficient way might be to send:

Cookie2: $Version="1"
Cookie: realoldnameA=realoldvalueA; realoldnameB=realoldvalueB[; ...]

If it's an old server or script, the Cookie2 request header will be
ignored.  Otherwise, the server or script will use Set-Cookie2, the
UA will not send the Cookie2 probe, and use Cookie: $Version="1"; ... 
so the updating is mutually know by the State Management partners
with negligable excess network traffic having been expended, and with
both the server/script and UA thereafter enjoyed all the benefits
of the modern State Management protocol.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Tuesday, 29 July 1997 11:55:33 UTC