view release on metacpan or  search on metacpan

rfc/rfc2109.txt  view on Meta::CPAN

   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.

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

   * To suppress caching of the Set-Cookie header: Cache-control: no-
     cache="set-cookie".

   and one of the following:

   * To suppress caching of a private document in shared caches: Cache-
     control: private.

   * To allow caching of a document and require that it be validated
     before returning it to the client: Cache-control: must-revalidate.

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

   * 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-Cookie response
   headers unless they know for certain (by out of band means) that
   there are no downsteam HTTP/1.0 proxies.  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.



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


4.3  User Agent Role

4.3.1  Interpreting Set-Cookie

   The user agent keeps separate track of state information that arrives
   via Set-Cookie response headers from each origin server (as
   distinguished by name or IP address and port).  The user agent
   applies these defaults for optional attributes that are missing:

   VersionDefaults to "old cookie" behavior as originally specified by
          Netscape.  See the HISTORICAL section.

   Domain Defaults to the request-host.  (Note that there is no dot at
          the beginning of request-host.)

   Max-AgeThe 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-Cookie response, up to, but not including, the
          right-most /.

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

4.3.2  Rejecting Cookies

   To prevent possible security or privacy violations, a user agent
   rejects a cookie (shall not store its information) if any of the
   following is true:

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

   * The value for the Domain attribute contains no embedded dots or
     does not start with a dot.

   * The value for the request-host does not domain-match the Domain
     attribute.

   * The request-host is a FQDN (not IP address) and has the form HD,
     where D is the value of the Domain attribute, and H is a string