Should a cookie with the host-only-flag replace a cookie without it?

Question

RFC 6265 states that a user-agent should proceed in the following way when receiving a Set-Cookie header:

If the Domain attribute is set:

• Set the cookie's domain to the domain-attribute.
• Set the cookie's host-only-flag to false.

If the Domain attribute is not set:

• Set the cookie's domain to the canonicalized request-host.
• Set the cookie's host-only-flag to true.

This is all clear. The confusion comes with this paragraph:

If the user agent receives a new cookie with the same cookie-name, domain-value, and path-value as a cookie that it has already stored, the existing cookie is evicted and replaced with the new cookie.

Let's take an example, with two cookies received on the domain www.example.com:

Set-cookie: name=value
Set-Cookie: name=value; Domain=www.example.com

The domain (and path) will be the same for both cookies, but the first one will have the host-only-flag set to true, and the second one to false.

Reading the RFC, it looks like it doesn't matter when comparing the two cookies, and they should be considered equivalent anyway, but I'm not sure my interpretation is correct.

Should the user-agent replace the first cookie with the second one, or should it store both of them?

Answer 1

The paragraph that confuses you is about the ability to assign a new value to a cookie (as well as changing/refreshing the cookie expiration date). If it were not written that way, the HTTP client would need to store multiple cookies with the same name could and it would need to decide on another criterium which to send to the HTTP server upon the next request.

Regarding the second part of your question:

If those two cookies are specified within the same request, the second one "wins", therefore a cookie with the host-only-flag = false would be stored.

If those two cookies come in separate requests, the second one overwrites the first one, because they match in cookie-name (specified), domain-value (once specified, once derived), and path-value (derived). When storing them, the entries in the browser's cookie database only differ in the host-only-flag.

This host-only-flag comes into effect when the client issues a new request to the server (snippet from RFC6265):

The user agent MUST use an algorithm equivalent to the following
algorithm to compute the "cookie-string" from a cookie store and a
request-uri:

1.  Let cookie-list be the set of cookies from the cookie store that
    meets all of the following requirements:

    *  Either:

           The cookie's host-only-flag is true and the canonicalized
           request-host is identical to the cookie's domain.

        Or:

           The cookie's host-only-flag is false and the canonicalized
           request-host domain-matches the cookie's domain.

The fine detail is in how the domain is compared. The matching algorithm is specified in section 5.1.3.

Essentially you can have a cookie be valid for all subdomains if the domain is specified with a leading "."

When the domain is omitted, though, (and therefore implied by the server from the request), this can never be the case because there always needs to be an identical match in the domain.

Further research determined:

In practice browsers store a domain that has been specified in the cookie with a prepended . (for www.example.com it will store .www.example.com) so that a request to subdomain.www.example.com will also return that cookie. When no domain is specified the plain domain without a prepended . will be stored, thus a request to a subdomain will not include that cookie.