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

"David W. Morris" <dwm@xpasc.com> wrote:
>
>On Tue, 29 Jul 1997, David W. Morris wrote:
>> 
>> On Tue, 29 Jul 1997, Foteos Macrides wrote:
>> 
>> > dmk@research.bell-labs.com (Dave Kristol) wrote:
>> > >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
>> > [...]
>> 
>> 
>> What if the client sends the $version= by itself? It is legal to send
>> multiple cookie headers and while folding is possible in theory, I'd
>> guess it doesn't happen much in practice, but could be wrong, and the
>> folding wouldn't be applied to an unknown header field name...
>
>Anyway, getting rejected by a verification site probably isn't a problem?

	If it's not a verification site, then the only "feedback" you
might get is that your "preferences" cookie didn't get you a document
with your display preferences, or you might infer a cookie exchange
snafoo that caused items to fall out of your "shopping cart" when you
attempt to make a purchase and don't get anything, or not everything
you wanted to buy, etc., etc.

	The historical implementation did not adhere to standard MIME
header construction and parsing principles.  And many scripts for
handling historical cookies were written by people who don't know
those principles, any more than they know the difference between
302 versus 303 statuses, but simply used their BrandX UA as if it
were a validator for their scripts.  After having field tested a
UA's implementation of historical Set-Cookie parsing and historical
Cookie transmissions, the implementors may be reluctant to mess
around with an implementation which works "well enough" most of the
time.

	By adding an explicit Cookie2: $Version="1" (or equivalent)
probe header, historical servers/scripts and UAs can go on conducting
business as usual, and while the majority of deployed UAs are historical,
any server/script can use only Set-Cookie headers without concern that
that modern UAs will not be detected and a switch to Set-Cookie2 headers
be made immediately.  Conversely, designers of servers and script writers
who feel that the attributes of the modern State Management protocol are
critically important, e.g. for its additional protections against Cookie
Spoofing (see Section 8.2 of the current pre-draft), or because they need
the port attribute honored, etc., can send only Set-Cookie2 headers and
make there stateful pages useful to progessively more UAs as their
implementors catch up.  Everyone can have his/her cake and eat it too,
even if initially it's just crumbs for some.

	Scripts which take advantage of the modern State Management
protocol can be written and used immediately, by anyone with programming
skills, and shared with non-programmers.  Similarly, modern servers are
readily extensible.  It thus makes the most sense for the UA to signal
its cookie handling capabilities to the server/script.

				Fote

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

Received on Tuesday, 29 July 1997 12:22:57 UTC