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.






 
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




 
RFC 2109            HTTP State Management Mechanism        February 1997