view release on metacpan or  search on metacpan

rfc/rfc2109.txt  view on Meta::CPAN

   rules detailed below, with every request.

   An origin server may include multiple Set-Cookie headers in a
   response.  Note that an intervening gateway could fold multiple such
   headers into a single header.

4.2.2  Set-Cookie Syntax

   The syntax for the Set-Cookie response header is

   set-cookie      =       "Set-Cookie:" cookies
   cookies         =       1#cookie
   cookie          =       NAME "=" VALUE *(";" cookie-av)
   NAME            =       attr
   VALUE           =       value
   cookie-av       =       "Comment" "=" value
                   |       "Domain" "=" value
                   |       "Max-Age" "=" value
                   |       "Path" "=" value
                   |       "Secure"
                   |       "Version" "=" 1*DIGIT

   Informally, the Set-Cookie response header comprises the token Set-
   Cookie:, followed by a comma-separated list of one or more cookies.
   Each cookie begins with a NAME=VALUE pair, followed by zero or more
   semi-colon-separated attribute-value pairs.  The syntax for
   attribute-value pairs was shown earlier.  The specific attributes and
   the semantics of their values follows.  The NAME=VALUE attribute-
   value pair must come first in each cookie.  The others, if present,
   can occur in any order.  If an attribute appears more than once in a
   cookie, the behavior is undefined.

   NAME=VALUE
      Required.  The name of the state information ("cookie") is NAME,
      and its value is VALUE.  NAMEs that begin with $ are reserved for
      other uses and must not be used by applications.








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


      The VALUE is opaque to the user agent and may be anything the
      origin server chooses to send, possibly in a server-selected
      printable ASCII encoding.  "Opaque" implies that the content is of
      interest and relevance only to the origin server.  The content
      may, in fact, be readable by anyone that examines the Set-Cookie
      header.

   Comment=comment
      Optional.  Because cookies can contain private information about a
      user, the Cookie attribute allows an origin server to document its
      intended use of a cookie.  The user can inspect the information to
      decide whether to initiate or continue a session with this cookie.

   Domain=domain
      Optional.  The Domain attribute specifies the domain for which the
      cookie is valid.  An explicitly specified domain must always start
      with a dot.

   Max-Age=delta-seconds
      Optional.  The Max-Age attribute defines the lifetime of the
      cookie, in seconds.  The delta-seconds value is a decimal non-
      negative integer.  After delta-seconds seconds elapse, the client
      should discard the cookie.  A value of zero means the cookie
      should be discarded immediately.

   Path=path
      Optional.  The Path attribute specifies the subset of URLs to
      which this cookie applies.

   Secure
      Optional.  The Secure attribute (with no value) directs the user
      agent to use only (unspecified) secure means to contact the origin
      server whenever it sends back this cookie.

      The user agent (possibly under the user's control) may determine
      what level of security it considers appropriate for "secure"
      cookies.  The Secure attribute should be considered security
      advice from the server to the user agent, indicating that it is in
      the session's interest to protect the cookie contents.

   Version=version
      Required.  The Version attribute, a decimal integer, identifies to
      which version of the state management specification the cookie
      conforms.  For this specification, Version=1 applies.







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


4.2.3  Controlling Caching

   An origin server must be cognizant of the effect of possible caching
   of both the returned resource and the Set-Cookie header.  Caching
   "public" documents is desirable.  For example, if the origin server
   wants to use a public document such as a "front door" page as a
   sentinel to indicate the beginning of a session for which a Set-
   Cookie response header must be generated, the page should be stored
   in caches "pre-expired" so that the origin server will see further
   requests.  "Private documents", for example those that contain
   information strictly private to a session, should not be cached in
   shared caches.

   If the cookie is intended for use by a single user, the Set-cookie
   header should not be cached.  A Set-cookie header that is intended to
   be shared by multiple users may be cached.

rfc/rfc2109.txt  view on Meta::CPAN

   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.