rfc2109.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,180 行 · 第 1/3 页

   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.

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

6.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 size of the
        characters that comprise the cookie non-terminal in the syntax
        description of the Set-Cookie 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-Cookie 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.





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


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

7.  PRIVACY

7.1  User Agent Control

   An origin server could create a Set-Cookie 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 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 by, for example, mechanisms

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

      * to display a visual indication that a stateful session is in
        progress.

      * to let the user decide which cookies, if any, should be saved
        when the user concludes a window or user agent session.

      * to let the user examine the contents of a cookie at any time.

   A user agent usually begins execution with no remembered state
   information.  It should be possible to configure a user agent never
   to send Cookie headers, in which case it can never sustain state with



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


   an origin server.  (The user agent would then behave like one that is
   unaware of how to handle Set-Cookie response headers.)

   When the user agent terminates execution, it should let the user
   discard all state information.  Alternatively, the user agent may ask
   the user whether state information should be retained; the default
   should be "no".  If the user chooses to retain state information, it
   would be restored the next time the user agent runs.

   NOTE: User agents should probably be cautious about using files to
   store cookies long-term.  If a user runs more than one instance of
   the user agent, the cookies could be commingled or otherwise messed
   up.

7.2  Protocol Design

   The restrictions on the value of the Domain attribute, and the rules
   concerning unverifiable transactions, are meant to reduce the ways
   that cookies can "leak" to the "wrong" site.  The intent is to
   restrict cookies to one, or a closely related set of hosts.
   Therefore a request-host is limited as to what values it can set for
   Domain.  We consider it acceptable for hosts host1.foo.com and
   host2.foo.com to share cookies, but not a.com and b.com.

   Similarly, a server can only set a Path for cookies that are related
   to the request-URI.

8.  SECURITY CONSIDERATIONS

8.1  Clear Text

   The information in the Set-Cookie and Cookie headers is unprotected.
   Two consequences are:

   1.  Any sensitive information that is conveyed in them is exposed
       to intruders.

   2.  A malicious intermediary could alter the headers as they travel
       in either direction, with unpredictable results.

   These facts imply that information of a personal and/or financial
   nature should only be sent over a secure channel.  For less sensitive
   information, or when the content of the header is a database key, an
   origin server should be vigilant to prevent a bad Cookie value from
   causing failures.






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


8.2  Cookie Spoofing

   Proper application design can avoid spoofing attacks from related
   domains.  Consider:

     1.  User agent makes request to victim.cracker.edu, gets back
         cookie session_id="1234" and sets the default domain
         victim.cracker.edu.

     2.  User agent makes request to spoof.cracker.edu, gets back
         cookie session-id="1111", with Domain=".cracker.edu".

     3.  User agent makes request to victim.cracker.edu again, and
         passes

         Cookie: $Version="1";
                         session_id="1234";
                         session_id="1111"; $Domain=".cracker.edu"

         The server at victim.cracker.edu should detect that the second
         cookie was not one it originated by noticing that the Domain
         attribute is not for itself and ignore it.

8.3  Unexpected Cookie Sharing

   A user agent should make every attempt to prevent the sharing of
   session information between hosts that are in different domains.
   Embedded or inlined objects may cause particularly severe privacy
   problems if they can be used to share cookies between disparate
   hosts.  For example, a malicious server could embed cookie
   information for host a.com in a URI for a CGI on host b.com.  User
   agent implementors are strongly encouraged to prevent this sort of
   exchange whenever possible.

9.  OTHER, SIMILAR, PROPOSALS

   Three other proposals have been made to accomplish similar goals.
   This specification is an amalgam of Kristol's State-Info proposal and
   Netscape's Cookie proposal.

   Brian Behlendorf proposed a Session-ID header that would be user-
   agent-initiated and could be used by an origin server to track
   "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.






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






Kristol & Montulli          Standards Track                    [Page 19]

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
   Set-Cookie header is stored in the cache, and, although the document
   is stale (expired), the cache returns the document in response to
   later requests, including cached headers.

11.  ACKNOWLEDGEMENTS

   This document really represents the collective efforts of the
   following people, in addition to the authors: Roy Fielding, Marc
   Hedlund, Ted Hardie, Koen Holtman, Shel Kaphan, Rohit Khare.












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


12.  AUTHORS' ADDRESSES

   David M. Kristol
   Bell Laboratories, Lucent Technologies
   600 Mountain Ave.  Room 2A-227
   Murray Hill, NJ  07974

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Lou Montulli
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA  94043

   Phone: [phone]
   EMail: [e-mail]
































Kristol & Montulli          Standards Track                    [Page 21]