rfc2109.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,180 行 · 第 1/3 页


RFC 2109            HTTP State Management Mechanism        February 1997


   * A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
     be accepted.

   * A Set-Cookie with Domain=.com or Domain=.com., will always be
     rejected, because there is no embedded dot.

   * A Set-Cookie with Domain=ajax.com will be rejected because the
     value for Domain does not begin with a dot.

4.3.3  Cookie Management

   If a user agent receives a Set-Cookie response header whose NAME is
   the same as a pre-existing cookie, and whose Domain and Path
   attribute values exactly (string) match those of a pre-existing
   cookie, the new cookie supersedes the old.  However, if the Set-
   Cookie has a value for Max-Age of zero, the (old and new) cookie is
   discarded.  Otherwise cookies accumulate until they expire (resources
   permitting), at which time they are discarded.

   Because user agents have finite space in which to store cookies, they
   may also discard older cookies to make space for newer ones, using,
   for example, a least-recently-used algorithm, along with constraints
   on the maximum number of cookies that each origin server may set.

   If a Set-Cookie response header includes a Comment attribute, the
   user agent should store that information in a human-readable form
   with the cookie and should display the comment text as part of a
   cookie inspection user interface.

   User agents should allow the user to control cookie destruction.  An
   infrequently-used cookie may function as a "preferences file" for
   network applications, and a user may wish to keep it even if it is
   the least-recently-used cookie.  One possible implementation would be
   an interface that allows the permanent storage of a cookie through a
   checkbox (or, conversely, its immediate destruction).

   Privacy considerations dictate that the user have considerable
   control over cookie management.  The PRIVACY section contains more
   information.

4.3.4  Sending Cookies to the Origin Server

   When it sends a request to an origin server, the user agent sends a
   Cookie request header to the origin server if it has cookies that are
   applicable to the request, based on

   * the request-host;




Kristol & Montulli          Standards Track                     [Page 8]

RFC 2109            HTTP State Management Mechanism        February 1997


   * the request-URI;

   * the cookie's age.

   The syntax for the header is:

   cookie          =       "Cookie:" cookie-version
                           1*((";" | ",") cookie-value)
   cookie-value    =       NAME "=" VALUE [";" path] [";" domain]
   cookie-version  =       "$Version" "=" value
   NAME            =       attr
   VALUE           =       value
   path            =       "$Path" "=" value
   domain          =       "$Domain" "=" value

   The value of the cookie-version attribute must be the value from the
   Version attribute, if any, of the corresponding Set-Cookie response
   header.  Otherwise the value for cookie-version is 0.  The value for
   the path attribute must be the value from the Path attribute, if any,
   of the corresponding Set-Cookie response header.  Otherwise the
   attribute should be omitted from the Cookie request header.  The
   value for the domain attribute must be the value from the Domain
   attribute, if any, of the corresponding Set-Cookie response header.
   Otherwise the attribute should be omitted from the Cookie request
   header.

   Note that there is no Comment attribute in the Cookie request header
   corresponding to the one in the Set-Cookie response header.  The user
   agent does not return the comment information to the origin server.

   The following rules apply to choosing applicable cookie-values from
   among all the cookies the user agent has.

   Domain Selection
        The origin server's fully-qualified host name must domain-match
        the Domain attribute of the cookie.

   Path Selection
        The Path attribute of the cookie must match a prefix of the
        request-URI.

   Max-Age Selection
        Cookies that have expired should have been discarded and thus
        are not forwarded to an origin server.







Kristol & Montulli          Standards Track                     [Page 9]

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



Kristol & Montulli          Standards Track                    [Page 10]

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
   document content is to facilitate the scaling that caching permits.
   To support cookies, a caching proxy must obey these rules already in
   the HTTP specification:

   * Honor requests from the cache, if possible, based on cache validity
     rules.

   * Pass along a Cookie request header in any request that the proxy
     must make of another server.

   * Return the response to the client.  Include any Set-Cookie response
     header.





Kristol & Montulli          Standards Track                    [Page 11]

RFC 2109            HTTP State Management Mechanism        February 1997


   * Cache the received response subject to the control of the usual
     headers, such as Expires, Cache-control: no-cache, and Cache-
     control: private,

   * Cache the Set-Cookie subject to the control of the usual header,
     Cache-control: no-cache="set-cookie".  (The Set-Cookie header
     should usually not be cached.)

   Proxies must not introduce Set-Cookie (Cookie) headers of their own
   in proxy responses (requests).

5.  EXAMPLES

5.1  Example 1

   Most detail of request and response headers has been omitted.  Assume
   the user agent has no stored cookies.

     1.  User Agent -> Server

         POST /acme/login HTTP/1.1
         [form data]

         User identifies self via a form.

     2.  Server -> User Agent

         HTTP/1.1 200 OK
         Set-Cookie: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"

         Cookie reflects user's identity.

     3.  User Agent -> Server

         POST /acme/pickitem HTTP/1.1
         Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
         [form data]

         User selects an item for "shopping basket."

     4.  Server -> User Agent

         HTTP/1.1 200 OK
         Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
                 Path="/acme"

         Shopping basket contains an item.




Kristol & Montulli          Standards Track                    [Page 12]

RFC 2109            HTTP State Management Mechanism        February 1997


     5.  User Agent -> Server

         POST /acme/shipping HTTP/1.1
         Cookie: $Version="1";
                 Customer="WILE_E_COYOTE"; $Path="/acme";
                 Part_Number="Rocket_Launcher_0001"; $Path="/acme"
         [form data]

         User selects shipping method from form.

     6.  Server -> User Agent

         HTTP/1.1 200 OK
         Set-Cookie: Shipping="FedEx"; Version="1"; Path="/acme"

         New cookie reflects shipping method.

     7.  User Agent -> Server

         POST /acme/process HTTP/1.1
         Cookie: $Version="1";
                 Customer="WILE_E_COYOTE"; $Path="/acme";
                 Part_Number="Rocket_Launcher_0001"; $Path="/acme";
                 Shipping="FedEx"; $Path="/acme"
         [form data]

         User chooses to process order.

     8.  Server -> User Agent

         HTTP/1.1 200 OK

         Transaction is complete.

   The user agent makes a series of requests on the origin server, after
   each of which it receives a new cookie.  All the cookies have the
   same Path attribute and (default) domain.  Because the request URLs
   all have /acme as a prefix, and that matches the Path attribute, each
   request contains all the cookies received so far.

5.2  Example 2

   This example illustrates the effect of the Path attribute.  All
   detail of request and response headers has been omitted.  Assume the
   user agent has no stored cookies.

   Imagine the user agent has received, in response to earlier requests,
   the response headers



Kristol & Montulli          Standards Track                    [Page 13]

RFC 2109            HTTP State Management Mechanism        February 1997


   Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
           Path="/acme"

   and

   Set-Cookie: Part_Number="Riding_Rocket_0023"; Version="1";
           Path="/acme/ammo"

   A subsequent request by the user agent to the (same) server for URLs
   of the form /acme/ammo/...  would include the following request
   header:

   Cookie: $Version="1";
           Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
           Part_Number="Rocket_Launcher_0001"; $Path="/acme"

   Note that the NAME=VALUE pair for the cookie with the more specific
   Path attribute, /acme/ammo, comes before the one with the less
   specific Path attribute, /acme.  Further note that the same cookie
   name appears more than once.

   A subsequent request by the user agent to the (same) server for a URL
   of the form /acme/parts/ would include the following request header:

   Cookie: $Version="1"; Part_Number="Rocket_Launcher_0001"; $Path="/acme"

   Here, the second cookie's Path attribute /acme/ammo is not a prefix
   of the request URL, /acme/parts/, so the cookie does not get
   forwarded to the server.

6.  IMPLEMENTATION CONSIDERATIONS

   Here we speculate on likely or desirable details for an origin server
   that implements state management.

6.1  Set-Cookie Content

   An origin server's content should probably be divided into disjoint
   application areas, some of which require the use of state
   information.  The application areas can be distinguished by their
   request URLs.  The Set-Cookie header can incorporate information
   about the application areas by setting the Path attribute for each
   one.

   The session information can obviously be clear or encoded text that
   describes state.  However, if it grows too large, it can become
   unwieldy.  Therefore, an implementor might choose for the session
   information to be a key to a server-side resource.  Of course, using



Kristol & Montulli          Standards Track                    [Page 14]

RFC 2109            HTTP State Management Mechanism        February 1997