* A Set-Cookie with Domain=.com or Domain=.com., will always be
     rejected, because there is no embedded dot.

   * A Set-Cookie with Domain=ajax.com will be rejected because the
     value for Domain does not begin with a dot.

4.3.3  Cookie Management

   If a user agent receives a Set-Cookie response header whose NAME is
   the same as a pre-existing cookie, and whose Domain and Path
   attribute values exactly (string) match those of a pre-existing
   cookie, the new cookie supersedes the old.  However, if the Set-
   Cookie has a value for Max-Age of zero, the (old and new) cookie is
   discarded.  Otherwise cookies accumulate until they expire (resources
   permitting), at which time they are discarded.

   Because user agents have finite space in which to store cookies, they
   may also discard older cookies to make space for newer ones, using,
   for example, a least-recently-used algorithm, along with constraints
   on the maximum number of cookies that each origin server may set.

   If a Set-Cookie response header includes a Comment attribute, the
   user agent should store that information in a human-readable form
   with the cookie and should display the comment text as part of a
   cookie inspection user interface.

   User agents should allow the user to control cookie destruction.  An
   infrequently-used cookie may function as a "preferences file" for
   network applications, and a user may wish to keep it even if it is
   the least-recently-used cookie.  One possible implementation would be
   an interface that allows the permanent storage of a cookie through a
   checkbox (or, conversely, its immediate destruction).

   Privacy considerations dictate that the user have considerable
   control over cookie management.  The PRIVACY section contains more
   information.

4.3.4  Sending Cookies to the Origin Server

   When it sends a request to an origin server, the user agent sends a
   Cookie request header to the origin server if it has cookies that are
   applicable to the request, based on

   * the request-host;





 
RFC 2109            HTTP State Management Mechanism        February 1997


   * the request-URI;

   * the cookie's age.

   The syntax for the header is:

   cookie          =       "Cookie:" cookie-version
                           1*((";" | ",") cookie-value)
   cookie-value    =       NAME "=" VALUE [";" path] [";" domain]
   cookie-version  =       "$Version" "=" value
   NAME            =       attr
   VALUE           =       value
   path            =       "$Path" "=" value
   domain          =       "$Domain" "=" value

   The value of the cookie-version attribute must be the value from the
   Version attribute, if any, of the corresponding Set-Cookie response
   header.  Otherwise the value for cookie-version is 0.  The value for
   the path attribute must be the value from the Path attribute, if any,
   of the corresponding Set-Cookie response header.  Otherwise the
   attribute should be omitted from the Cookie request header.  The
   value for the domain attribute must be the value from the Domain
   attribute, if any, of the corresponding Set-Cookie response header.
   Otherwise the attribute should be omitted from the Cookie request
   header.

   Note that there is no Comment attribute in the Cookie request header
   corresponding to the one in the Set-Cookie response header.  The user
   agent does not return the comment information to the origin server.

   The following rules apply to choosing applicable cookie-values from
   among all the cookies the user agent has.

   Domain Selection
        The origin server's fully-qualified host name must domain-match
        the Domain attribute of the cookie.

   Path Selection
        The Path attribute of the cookie must match a prefix of the
        request-URI.

   Max-Age Selection
        Cookies that have expired should have been discarded and thus
        are not forwarded to an origin server.