rfc2965.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2965            HTTP State Management Mechanism         October 2000


   When it makes an unverifiable transaction, a user agent MUST disable
   all cookie processing (i.e., MUST NOT send cookies, and MUST NOT
   accept any received cookies) if the transaction is to a third-party
   host.

   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".

   (N.B.  Mechanisms may be proposed that will automate overriding the
   third-party restrictions under controlled conditions.)

   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
   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.

3.4  How an Origin Server Interprets the Cookie Header

   A user agent returns much of the information in the Set-Cookie2
   header to the origin server when the request-URI path-matches the
   Path attribute of the cookie.  When it receives a Cookie header, the
   origin server SHOULD treat cookies with NAMEs whose prefix is $
   specially, as an attribute for the cookie.








Kristol & Montulli          Standards Track                    [Page 14]

RFC 2965            HTTP State Management Mechanism         October 2000


3.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-Cookie2
         response header.

      *  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-Cookie2 subject to the control of the usual
         header,

         Cache-control: no-cache="set-cookie2"

         (The Set-Cookie2 header should usually not be cached.)

   Proxies MUST NOT introduce Set-Cookie2 (Cookie) headers of their own
   in proxy responses (requests).

4.  EXAMPLES

4.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.



Kristol & Montulli          Standards Track                    [Page 15]

RFC 2965            HTTP State Management Mechanism         October 2000


      2. Server -> User Agent

        HTTP/1.1 200 OK
        Set-Cookie2: 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-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
                Path="/acme"

        Shopping basket contains an item.

      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-Cookie2: 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]



Kristol & Montulli          Standards Track                    [Page 16]

RFC 2965            HTTP State Management Mechanism         October 2000


        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-URIs
   all path-match /acme, the Path attribute of each cookie, each request
   contains all the cookies received so far.

4.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

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

   and

   Set-Cookie2: 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:





Kristol & Montulli          Standards Track                    [Page 17]

RFC 2965            HTTP State Management Mechanism         October 2000


   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.

5.  IMPLEMENTATION CONSIDERATIONS

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

5.1  Set-Cookie2 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-Cookie2 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
   a database creates some problems that this state management
   specification 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.

5.2  Stateless Pages

   Caching benefits the scalability of WWW.  Therefore it is important
   to reduce the number of documents that have state embedded in them
   inherently.  For example, if a shopping-basket-style application
   always displays a user's current basket contents on each page, those
   pages cannot be cached, because each user's basket's contents would
   be different.  On the other hand, if each page contains just a link
   that allows the user to "Look at My Shopping Basket", the page can be
   cached.








Kristol & Montulli          Standards Track                    [Page 18]

RFC 2965            HTTP State Management Mechanism         October 2000


5.3  Implementation Limits

   Practical user agent implementations have limits on the number and
   size of cookies that they can store.  In general, user agents' cookie
   support should have no fixed limits.  They should strive to store as
   many frequently-used cookies as possible.  Furthermore, general-use
   user agents SHOULD provide each of the following minimum capabilities
   individually, although not necessarily simultaneously:

      *  at least 300 cookies

      *  at least 4096 bytes per cookie (as measured by the characters
         that comprise the cookie non-terminal in the syntax description
         of the Set-Cookie2 header, and as received in the Set-Cookie2
         header)

      *  at least 20 cookies per unique host or domain name

   User agents created for specific purposes or for limited-capacity
   devices SHOULD provide at least 20 cookies of 4096 bytes, to ensure
   that the user can interact with a session-based origin server.

   The information in a Set-Cookie2 response header MUST be retained in
   its entirety.  If for some reason there is inadequate space to store
   the cookie, it MUST be discarded, not truncated.

   Applications should use as few and as small cookies as possible, and
   they should cope gracefully with the loss of a cookie.

   5.3.1  Denial of Service Attacks  User agents MAY choose to set an
   upper bound on the number of cookies to be stored from a given host
   or domain name or on the size of the cookie information.  Otherwise a
   malicious server could attempt to flood a user agent with many
   cookies, or large cookies, on successive responses, which would force
   out cookies the user agent had received from other servers.  However,
   the minima specified above SHOULD still be supported.

6.  PRIVACY

   Informed consent should guide the design of systems that use cookies.
   A user should be able to find out how a web site plans to use
   information in a cookie and should be able to choose whether or not
   those policies are acceptable.  Both the user agent and the origin
   server must assist informed consent.







Kristol & Montulli          Standards Track                    [Page 19]

RFC 2965            HTTP State Management Mechanism         October 2000


6.1  User Agent Control

   An origin server could create a Set-Cookie2 header to track the path
   of a user through the server.  Users may object to this behavior as
   an intrusive accumulation of information, even if their identity is
   not evident.  (Identity might become evident, for example, if a user
   subsequently fills out a form that contains identifying information.)
   This state management specification therefore requires that a user
   agent give the user control over such a possible intrusion, although
   the interface through which the user is given this control is left
   unspecified.  However, the control mechanisms provided SHALL at least
   allow the user

      *  to completely disable the sending and saving of cookies.

      *  to determine whether a stateful session is in progress.

      *  to control the saving of a cookie on the basis of the cookie's
         Domain attribute.

   Such control could be provided, for example, by mechanisms

      *  to notify the user when the user agent is about to send a
         cookie to the origin server, to offer the option not to begin a
         session.