W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

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

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Tue, 29 Jul 1997 11:57:55 -0500 (EST)
To: cuckoo.hpl.hp.com@http-wg.uucp, http-state@lists.research.bell-labs.com
Message-Id: <01ILT3O3B5AQ00517U@SCI.WFBR.EDU>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3982

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

   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.


 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC