"clicktrails".  It would not carry any origin-server-defined state,
   however.  Phillip Hallam-Baker has proposed another client-defined
   session ID mechanism for similar purposes.







 
RFC 2109            HTTP State Management Mechanism        February 1997


   While both session IDs and cookies can provide a way to sustain
   stateful sessions, their intended purpose is different, and,
   consequently, the privacy requirements for them are different.  A
   user initiates session IDs to allow servers to track progress through
   them, or to distinguish multiple users on a shared machine.  Cookies
   are server-initiated, so the cookie mechanism described here gives
   users control over something that would otherwise take place without
   the users' awareness.  Furthermore, cookies convey rich, server-
   selected information, whereas session IDs comprise user-selected,
   simple information.

10.  HISTORICAL

10.1  Compatibility With Netscape's Implementation

   HTTP/1.0 clients and servers may use Set-Cookie and Cookie headers
   that reflect Netscape's original cookie proposal.  These notes cover
   inter-operation between "old" and "new" cookies.

10.1.1  Extended Cookie Header

   This proposal adds attribute-value pairs to the Cookie request header
   in a compatible way.  An "old" client that receives a "new" cookie
   will ignore attributes it does not understand; it returns what it
   does understand to the origin server.  A "new" client always sends
   cookies in the new form.

   An "old" server that receives a "new" cookie will see what it thinks
   are many cookies with names that begin with a $, and it will ignore
   them.  (The "old" server expects these cookies to be separated by
   semi-colon, not comma.)  A "new" server can detect cookies that have
   passed through an "old" client, because they lack a $Version
   attribute.

10.1.2  Expires and Max-Age

   Netscape's original proposal defined an Expires header that took a
   date value in a fixed-length variant format in place of Max-Age:

   Wdy, DD-Mon-YY HH:MM:SS GMT

   Note that the Expires date format contains embedded spaces, and that
   "old" cookies did not have quotes around values.  Clients that
   implement to this specification should be aware of "old" cookies and
   Expires.







 
RFC 2109            HTTP State Management Mechanism        February 1997


10.1.3  Punctuation

   In Netscape's original proposal, the values in attribute-value pairs
   did not accept "-quoted strings.  Origin servers should be cautious
   about sending values that require quotes unless they know the
   receiving user agent understands them (i.e., "new" cookies).  A
   ("new") user agent should only use quotes around values in Cookie
   headers when the cookie's version(s) is (are) all compliant with this
   specification or later.

   In Netscape's original proposal, no whitespace was permitted around
   the = that separates attribute-value pairs.  Therefore such
   whitespace should be used with caution in new implementations.

10.2  Caching and HTTP/1.0

   Some caches, such as those conforming to HTTP/1.0, will inevitably
   cache the Set-Cookie header, because there was no mechanism to
   suppress caching of headers prior to HTTP/1.1.  This caching can lead
   to security problems.  Documents transmitted by an origin server
   along with Set-Cookie headers will usually either be uncachable, or
   will be "pre-expired".  As long as caches obey instructions not to
   cache documents (following Expires: <a date in the past> or Pragma:
   no-cache (HTTP/1.0), or Cache-control: no-cache (HTTP/1.1))
   uncachable documents present no problem.  However, pre-expired
   documents may be stored in caches.  They require validation (a
   conditional GET) on each new request, but some cache operators loosen
   the rules for their caches, and sometimes serve expired documents
   without first validating them.  This combination of factors can lead
   to cookies meant for one user later being sent to another user.  The