[
Lists Home |
Date Index |
Thread Index
]
Your privacy argument is fairly bogus -- the cookie still gets sent on
the wire in the clear with every request. In any case, there is a
difference between passing "private data" as state between client and
server on every request (which is bad whether done with cookies or URL)
and using a session token to match a client with server state, which is
what I described. The latter is absolutely essential in any non-trivial
web application. I'll admit that there are reasons you would prefer to
store a session token in a cookie rather than URL, but not for the
reasons you describe (referrers can be easily managed). Embedding state
(especially transient state prone to expiration such as authentication)
makes it difficult to bookmark things, compare URIs, etc -- in short
violates REST.
> -----Original Message-----
> From: Bob Wyman [mailto:bob@wyman.us]
> Sent: Monday, January 05, 2004 2:35 PM
> To: Joshua Allen; 'Rich Salz'; 'Elliotte Rusty Harold'
> Cc: 'Edd Dumbill'; 'David Kunkel'; 'XML-DEV'
> Subject: RE: [xml-dev] Re: Cookies at XML Europe 2004 -- Call for
> Participation
>
> Joshua Allen wrote:
> > The login token stored in the cookie
> > can always be embedded in the URL path,
> One of the original motivations for doing cookies was to
> remove "state information" from the URL so that it wouldn't compromise
> privacy by showing up in referral string information. If you embed
> "cookies" in URL's you end up leaking private data between sites. This
> is not good.
> See www-talk archives for 1994 or so to see the discussions on
> "state management" (i.e. cookies).
>
> bob wyman
|
