view release on metacpan or  search on metacpan

rfc/rfc2965.txt  view on Meta::CPAN


RFC 2965            HTTP State Management Mechanism         October 2000


   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, to protect the
      confidentially and authenticity of the information in the cookie.

      The user agent (possibly with user interaction) 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.  When it sends a "secure"
      cookie back to a server, the user agent SHOULD use no less than
      the same level of security as was used when it received the cookie
      from the server.

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

   3.2.3  Controlling Caching  An origin server must be cognizant of the
   effect of possible caching of both the returned resource and the
   Set-Cookie2 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-Cookie2 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-Cookie2
   header SHOULD NOT be cached.  A Set-Cookie2 header that is intended
   to be shared by multiple users MAY be cached.

   The origin server SHOULD send the following additional HTTP/1.1
   response headers, depending on circumstances:

      *  To suppress caching of the Set-Cookie2 header:

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

   and one of the following:

      *  To suppress caching of a private document in shared caches:

         Cache-control: private



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


      *  To allow caching of a document and require that it be validated
         before returning it to the client:

         Cache-Control: must-revalidate, max-age=0

      *  To allow caching of a document, but to require that proxy
         caches (not user agent caches) validate it before returning it
         to the client:

         Cache-Control: proxy-revalidate, max-age=0

      *  To allow caching of a document and request that it be validated
         before returning it to the client (by "pre-expiring" it):

         Cache-control: max-age=0

         Not all caches will revalidate the document in every case.

   HTTP/1.1 servers MUST send Expires: old-date (where old-date is a
   date long in the past) on responses containing Set-Cookie2 response
   headers unless they know for certain (by out of band means) that
   there are no HTTP/1.0 proxies in the response chain.  HTTP/1.1
   servers MAY send other Cache-Control directives that permit caching
   by HTTP/1.1 proxies in addition to the Expires: old-date directive;
   the Cache-Control directive will override the Expires: old-date for
   HTTP/1.1 proxies.

3.3  User Agent Role

   3.3.1  Interpreting Set-Cookie2  The user agent keeps separate track
   of state information that arrives via Set-Cookie2 response headers
   from each origin server (as distinguished by name or IP address and
   port).  The user agent MUST ignore attribute-value pairs whose
   attribute it does not recognize.  The user agent applies these
   defaults for optional attributes that are missing:

   Discard The default behavior is dictated by the presence or absence
           of a Max-Age attribute.

   Domain  Defaults to the effective request-host.  (Note that because
           there is no dot at the beginning of effective request-host,
           the default Domain can only domain-match itself.)

   Max-Age The default behavior is to discard the cookie when the user
           agent exits.

   Path    Defaults to the path of the request URL that generated the
           Set-Cookie2 response, up to and including the right-most /.



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


   Port    The default behavior is that a cookie MAY be returned to any
           request-port.

   Secure  If absent, the user agent MAY send the cookie over an
           insecure channel.

   3.3.2  Rejecting Cookies  To prevent possible security or privacy
   violations, a user agent rejects a cookie according to rules below.
   The goal of the rules is to try to limit the set of servers for which
   a cookie is valid, based on the values of the Path, Domain, and Port
   attributes and the request-URI, request-host and request-port.

   A user agent rejects (SHALL NOT store its information) if the Version
   attribute is missing.  Moreover, a user agent rejects (SHALL NOT
   store its information) if any of the following is true of the
   attributes explicitly present in the Set-Cookie2 response header:

      *  The value for the Path attribute is not a prefix of the
         request-URI.

      *  The value for the Domain attribute contains no embedded dots,