- From: Marc Salomon <marc@ckm.ucsf.edu>
- Date: Thu, 20 Jun 1996 12:11:01 -0700
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Syntax:
The augmented BNF doesn't contain a comment keyword as per HTTP 1.1.
Translucence of the cookie is important, as the cookie speaks the server's data
on the user for the user at the user's command. A server's documentation of
the contents of its cookies can both aid a user in determining whether they
want to keep a cookie in their cookie jar, and could be used legally in certain
jurisdictions bind a content provider's representation of cookie functionality
to actual functionality to prevent abuses. The absence of cookie commentary
can be of value itself. This can be accomplished either by commenting each
chip in the cookie or by providing a URI as a link to a key describing this
flavor of cookie.
If adding comment to the grammar wouldn't break Navigator or any other existing
cookie implementations I'd like to add "comment" to the syntax and some text as
above to the privacy section.
|4.2.2 Set-Cookie Syntax The syntax for the Set-Cookie response header
|is
|
|set-cookie = "Set-Cookie:" cookies
|cookies = 1#cookie
!cookie = NAME "=" VALUE *(";" cookie-av *( comment ) )
and
|Version=version
| Required. The Version attribute, a decimal integer, identifies to
| which version of the state management specification the cookie
| conforms. For this specification, Version=1 applies.
+
+comment
+ HTTP comment as defined in RFC1945 section 2.2.
My take is that comments need not be included in the Cookie: header as they can
be cached by the UA at Set-Cookie time.
Security/Privacy:
|origin server. (The user agent would then behave like one that is
|unaware of how to handle Set-Cookie response headers.)
+If a browser has a kiosk mode for use as a public terminal, and is configured
+to accept cookies, then the user agent should be configurable to clear its
+cookie cache (and any other per-user authentication data), either by an
+explicit user "log out" command or by a timeout mechanism.
|When the user agent terminates execution, it should let the user discard
|all state information.
This would be a good case for a future client-side state advertisement of
"mode=kiosk" so that a server could bake its cookies appropriately for the
kiosk environment.
Graceful Deployment:
When this draft makes RFC will it be as if it had always been in the HTTP 1.1
spec? Will all conforming HTTP 1.1 user agents then be required to understand
cookies? Is it assumed that no response to a Set-Cookie means that Cookies are
not supported for that user agent?
6.1 Set-Cookie Content
|Therefore, an implementor might choose for the session information to be a key
|into a server-side database.
Therefore, an implementor might choose for the session information to be a key
to a server-side resource.
|Of course, using a database creates some problems that the state management
|proposal was meant to avoid, namely:
|
| 1. keeping real state on the server side;
|
| 2. how and when to garbage-collect the database entry, in case the
| user agent terminates the session by, for example, exiting.
Certain state/session applications require real server-side state, and that is
not inherently problematic. The current expedient technique of mixing state
and location information is the main problem that this proposal was meant to
avoid. Stateful application developers have been able to make the choice of
how much state to store in the URI (non-persistent using POST or persistent and
strlen(URI) <= max_env_var_len for GET) or on the server-side for years now.
The win with the cookie is that one can send those data cleanly through the
protocol as opposed to crudely through the URI.
9. OTHER, SIMILAR, PROPOSALS
|A user initiates session IDs to allow servers to track progress through them.
or to differentiate multiple instances of a user agent by possibly multiple
users on a single shared machine.
7.2 Protocol Design
|Therefore a request-host is limited as to what values it can set for Domain.
|We consider it acceptable for hosts host1.foo.com and host2.foo.com to
|share cookies, but not a.com and b.com.
I'm not a DNS guru, but it seems possible to use cookies, redirects and
cooperating DNS domains to achieve the 1:n cookie functionality in accordance
with this document:
Say that a.com and b.com conspire to create a new domain between them called
spy.com. In the DNS foo.a.com is also foo.spy.com and bar.b.com is also
bar.spy.com (perhaps multi-homed). One initiates a connection to foo.a.com,
recieves a redirect with a Set-Cookie (cookie-1) to foo.spy.com which itself
returns a Set-Cookie (cookie-2) for .spy.com.
a.com and b.com et al conspire to redirect all requests with cookie-1 to the
appropriate *.spy.com where cookie-2 is sent and the user is tracked. If this
is correct, then Set-Cookies in 302 responses are as dangerous to privacy as
1:n cookies.
-marc
--
Received on Thursday, 20 June 1996 12:17:26 UTC