RFC 2109            HTTP State Management Mechanism        February 1997


   If multiple cookies satisfy the criteria above, they are ordered in
   the Cookie header such that those with more specific Path attributes
   precede those with less specific.  Ordering with respect to other
   attributes (e.g., Domain) is unspecified.

   Note: For backward compatibility, the separator in the Cookie header
   is semi-colon (;) everywhere.  A server should also accept comma (,)
   as the separator between cookie-values for future compatibility.

4.3.5  Sending Cookies in Unverifiable Transactions

   Users must have control over sessions in order to ensure privacy.
   (See PRIVACY section below.)  To simplify implementation and to
   prevent an additional layer of complexity where adequate safeguards
   exist, however, this document distinguishes between transactions that
   are verifiable and those that are unverifiable.  A transaction is
   verifiable if the user has the option to review the request-URI prior
   to its use in the transaction.  A transaction is unverifiable if the
   user does not have that option.  Unverifiable transactions typically
   arise when a user agent automatically requests inlined or embedded
   entities or when it resolves redirection (3xx) responses from an
   origin server.  Typically the origin transaction, the transaction
   that the user initiates, is verifiable, and that transaction may
   directly or indirectly induce the user agent to make unverifiable
   transactions.

   When it makes an unverifiable transaction, a user agent must enable a
   session only if a cookie with a domain attribute D was sent or
   received in its origin transaction, such that the host name in the
   Request-URI of the unverifiable transaction domain-matches D.

   This restriction prevents a malicious service author from using
   unverifiable transactions to induce a user agent to start or continue
   a session with a server in a different domain.  The starting or
   continuation of such sessions could be contrary to the privacy
   expectations of the user, and could also be a security problem.

   User agents may offer configurable options that allow the user agent,
   or any autonomous programs that the user agent executes, to ignore
   the above rule, so long as these override options default to "off".

   Many current user agents already provide a review option that would
   render many links verifiable.  For instance, some user agents display
   the URL that would be referenced for a particular link when the mouse
   pointer is placed over that link.  The user can therefore determine
   whether to visit that site before causing the browser to do so.
   (Though not implemented on current user agents, a similar technique
   could be used for a button used to submit a form -- the user agent




 
RFC 2109            HTTP State Management Mechanism        February 1997


   could display the action to be taken if the user were to select that
   button.) However, even this would not make all links verifiable; for
   example, links to automatically loaded images would not normally be
   subject to "mouse pointer" verification.

   Many user agents also provide the option for a user to view the HTML
   source of a document, or to save the source to an external file where
   it can be viewed by another application.  While such an option does
   provide a crude review mechanism, some users might not consider it
   acceptable for this purpose.

4.4  How an Origin Server Interprets the Cookie Header

   A user agent returns much of the information in the Set-Cookie header
   to the origin server when the Path attribute matches that of a new
   request.  When it receives a Cookie header, the origin server should
   treat cookies with NAMEs whose prefix is $ specially, as an attribute
   for the adjacent cookie.  The value for such a NAME is to be
   interpreted as applying to the lexically (left-to-right) most recent
   cookie whose name does not have the $ prefix.  If there is no
   previous cookie, the value applies to the cookie mechanism as a
   whole.  For example, consider the cookie

   Cookie: $Version="1"; Customer="WILE_E_COYOTE";
           $Path="/acme"

   $Version applies to the cookie mechanism as a whole (and gives the
   version number for the cookie mechanism).  $Path is an attribute
   whose value (/acme) defines the Path attribute that was used when the
   Customer cookie was defined in a Set-Cookie response header.

4.5  Caching Proxy Role

   One reason for separating state information from both a URL and