- From: Lou Montulli <montulli@netscape.com>
- Date: Tue, 18 Apr 1995 12:33:12 -0700
- To: brian@organic.com, Multiple recipients of list <www-talk@www10.w3.org>
On Apr 17, 10:43pm, Brian Behlendorf wrote:
> Subject: Session tracking
>
> So, I'd like to propose for discussion a new HTTP header (hi Roy!) called
> "Session-ID". This would be optional, of course, and it would change any
> time the browser is restarted (or when the user wished). It would
> consist of a string of 32 random base 64 characters (or whatever encoding
> is allowed in headers). It would allow the content provider to see the
> "path" one takes through his system, even when two separate requests are
> interlacing through a proxy server (HotWired would often get 5
> individuals hitting it from antares.prodigy.com at the same time),
> without requiring user authentication or divulging of any personal
> information. The "From:" header would also work, but it would give away
> information that most would probably prefer not to give.
>
We have been doing some work along these lines. Here
is a proposal for a session based id that is capible
of storing id's accross user sessions. Hopefully
this can be polished up and added to the next HTTP
spec.
--------------------------------------------------
Syntax of the Set-Cookie HTTP Response Header:
Set-Cookie: NAME=OPAQUE_STRING \
[; expires= ] \
[; path=] \
[; domain=] \
[; secure]
Syntax of the Cookie HTTP Request Header:
Cookie: NAME=OPAQUE_STRING *[; NAME=OPAQUE_STRING]
Semantics:
The Set-Cookie tag, when sent from server to client as part of any HTTP
response, instructs the client to send the name/value pair using the
"Cookie:" header to the server whenever returning to the specified server
location.
The server location may be specified in several ways:
o "Set-Cookie" without any optional arguments specifies that all
subsequent requests to the same server within the subtree defined by
the referring URL will include the NAME=OPAQUE_STRING pair. The root
of the subtree is determined by stripping everything after the last
slash. For example, if the referring URL pointed to a file
"/foo/bar/baz.html" the root of the subtree will be defined by
"/foo/bar/".
o The "path" attribute, if present, specifies which path in the server
URL namespace forms the root of the tree for which requests shall
include the NAME=OPAQUE_STRING name/value pair. Note that the pat is
used as a mask value whereby any URL in the same server whose first
path characters exactly match the "path" string will match. Therefore
the path "/foo" would match "/foobar" and the "/foo/bar.html". The
path "/" is the most general path.
o The "domain" attribute, if present, specifies a server domain in the
form of a TCP/IP domain name. Note that the domain acts as a tail end
mask. All hosts within the specified domain will recieve the cookie
on subsequent requests. Only hosts within the specified domain can
set a cookie for a domain and domains must have at least two (2)
periods in them to prevent domains of the form: ".com" and ".edu".
".mcom.com" is an example of a valid domain.
o The "expires" attribute specifies an RFC 850 date string that
indicates when the cookie should be purged.
Also note that:
o Multiple "Set-Cookie" headers can be issued in a single server
response.
o Instances of the same path and name will overwrite each other, with
the latest instance taking precedence. Instances of the same path but
different names will add additional mappings.
o Setting the path to a higher-level value does not override other more
specific path mappings. Therefore you may receive a duplicate name
string if other mappings have been made for more specific
directories. (See examples below.)
o The "expires" attribute acts as an indication of when the client can
dispose of the "Set-Cookie" mapping. Clients are encouraged to hold
the string as long as possible or until the expires date has passed.
The expires header lets the client know when it is safe to purge the
mapping but the client is not required to do so. Clients should never
send a cookie to a server after the expires date has passed. Cookies
sent without an expires header are assumed to be short lived and
should be purged from the client at the end of the users session.
This is typically done when the user quits the client application.
o The "secure" attribute tells the client to only send the name/value
pair when speaking on a secure channel. This protects against the
case where the same server has secure and non-secure transactions
taking place on the same server and the transmission of the
name/value pair could be a security risk. (Note: if the port number
of the request is always taken into account when deciding whether to
send a name/value pair, this attribute is probably not actually
necessary at this time.)
o The client returns the OPAQUE_STRING to the server in the form of a
"Cookie: NAME=OPAQUE_STRING *[;NAME=OPAQUE_STRING]" header. The
name/value pairs can be spread among more than one "Cookie" header if
the client so chooses.
o Semi-colons, commas, and whitespace are not allowed in the
NAME=OPAQUE_STRING. Servers are expected to use an escaping mechanism
to send and read the NAME=OPAQUE_STRING. The '%xx' hex string
escaping mechanism used for URLs is recommended (a space character
maps to '%20', etc.).
o When sending cookies to a server, all cookies with a more specific
path mapping should be sent before cookies with less specific path
mappings. For example, a cookie "name1=foo" with a path mapping of
"/" should be sent in front of a cookie "name1=foo2" with a path
mapping of "/bar" if they are both to be sent.
--
Lou Montulli http://www.mcom.com/people/montulli/
Netscape Communications Corp.
Received on Tuesday, 18 April 1995 18:12:13 UTC