rfc2965.txt

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

      * 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 and delete 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
   an origin server.  (The user agent would then behave like one that is
   unaware of how to handle Set-Cookie2 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.





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


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

6.2  Origin Server Role

   An origin server SHOULD promote informed consent by adding CommentURL
   or Comment information to the cookies it sends.  CommentURL is
   preferred because of the opportunity to provide richer information in
   a multiplicity of languages.

6.3  Clear Text

   The information in the Set-Cookie2 and Cookie headers is unprotected.
   As a consequence:

      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.

   A user agent in a shared user environment poses a further risk.
   Using a cookie inspection interface, User B could examine the
   contents of cookies that were saved when User A used the machine.

7.  SECURITY CONSIDERATIONS

7.1  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 host, 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 set a Path only for cookies that are related
   to the request-URI.




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


7.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",
                 $Version="1"; 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.

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

7.4  Cookies For Account Information

   While it is common practice to use them this way, cookies are not
   designed or intended to be used to hold authentication information,
   such as account names and passwords.  Unless such cookies are
   exchanged over an encrypted path, the account information they
   contain is highly vulnerable to perusal and theft.

8.  OTHER, SIMILAR, PROPOSALS

   Apart from RFC 2109, three other proposals have been made to
   accomplish similar goals.  This specification began as an amalgam of
   Kristol's State-Info proposal [DMK95] and Netscape's Cookie proposal
   [Netscape].




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


   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.

   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.

9.  HISTORICAL

9.1  Compatibility with Existing Implementations

   Existing cookie implementations, based on the Netscape specification,
   use the Set-Cookie (not Set-Cookie2) header.  User agents that
   receive in the same response both a Set-Cookie and Set-Cookie2
   response header for the same cookie MUST discard the Set-Cookie
   information and use only the Set-Cookie2 information.  Furthermore, a
   user agent MUST assume, if it received a Set-Cookie2 response header,
   that the sending server complies with this document and will
   understand Cookie request headers that also follow this
   specification.

   New cookies MUST replace both equivalent old- and new-style cookies.
   That is, if a user agent that follows both this specification and
   Netscape's original specification receives a Set-Cookie2 response
   header, and the NAME and the Domain and Path attributes match (per
   the Cookie Management section) a Netscape-style cookie, the
   Netscape-style cookie MUST be discarded, and the user agent MUST
   retain only the cookie adhering to this specification.

   Older user agents that do not understand this specification, but that
   do understand Netscape's original specification, will not recognize
   the Set-Cookie2 response header and will receive and send cookies
   according to the older specification.








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


   A user agent that supports both this specification and Netscape-style
   cookies SHOULD send a Cookie request header that follows the older
   Netscape specification if it received the cookie in a Set-Cookie
   response header and not in a Set-Cookie2 response header.  However,
   it SHOULD send the following request header as well:

        Cookie2: $Version="1"

   The Cookie2 header advises the server that the user agent understands
   new-style cookies.  If the server understands new-style cookies, as
   well, it SHOULD continue the stateful session by sending a Set-
   Cookie2 response header, rather than Set-Cookie.  A server that does
   not understand new-style cookies will simply ignore the Cookie2
   request header.

9.2  Caching and HTTP/1.0

   Some caches, such as those conforming to HTTP/1.0, will inevitably
   cache the Set-Cookie2 and Set-Cookie headers, 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-Cookie2 and Set-Cookie headers usually
   either will 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-Cookie2 and Set-Cookie headers
   are stored in the cache, and, although the document is stale
   (expired), the cache returns the document in response to later
   requests, including cached headers.

10.  ACKNOWLEDGEMENTS

   This document really represents the collective efforts of the HTTP
   Working Group of the IETF and, particularly, the following people, in
   addition to the authors: Roy Fielding, Yaron Goland, Marc Hedlund,
   Ted Hardie, Koen Holtman, Shel Kaphan, Rohit Khare, Foteos Macrides,
   David W. Morris.








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


11.  AUTHORS' ADDRESSES

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

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


   Lou Montulli
   Epinions.com, Inc.
   2037 Landings Dr.
   Mountain View, CA  94301

   EMail: [e-mail]

12.  REFERENCES

   [DMK95]    Kristol, D.M., "Proposed HTTP State-Info Mechanism",
              available at <http://portal.research.bell-
              labs.com/~dmk/state-info.html>, September, 1995.

   [Netscape] "Persistent Client State -- HTTP Cookies", available at
              <http://www.netscape.com/newsref/std/cookie_spec.html>,
              undated.

   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2109, February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2279]  Yergeau, F., "UTF-8, a transformation format of Unicode
              and ISO-10646", RFC 2279, January 1998.

   [RFC2396]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
              RFC 2616, June 1999.






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


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Kristol & Montulli          Standards Track                    [Page 26]