If a cookie with a host-only flag replaces a cookie without it?

Question

RFC 6265 states that the user agent must act as follows when it receives the Set-Cookie header:

If the Domain attribute is set:

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

If the domain attribute is not set:

• Set the cookie domain to the canonized request node.
• Set the cookie host-only-flag to true only.

All clear. The confusion comes with this paragraph:

If the user agent receives a new cookie with the same cookie name, the domain value and path value as a cookie that he already saved, the existing cookie is supplanted and replaced with the new cookie.

Let's take an example with two cookies received in 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 will have a flag set only for the host true , and the second false .

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

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

Answer 1

The paragraph that bothers you is about the ability to set a new value for the cookie (as well as changing / updating the cookie expiration date). If this were not written, the HTTP client would have to store several cookies with the same name, and it would have to solve a different criterion, which would be sent to the HTTP server after the next request.

Regarding the second part of your question:

If these two cookies are specified in one request, the second "wins", so the cookie with host-only-flag = false will be saved.

If these two cookies come in separate requests, the second one overwrites the first, since they coincide with the cookie name (specified), domain value (after the specified, after receiving) and path value (derived). When stored, the entries in the browser cookie database differ only in the host-only flag.

This host-only flag takes effect when the client issues a new request to the server ( fragment 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 host-only-flag is true and the canonicalized request-host is identical to the cookie domain. Or: The cookie host-only-flag is false and the canonicalized request-host domain-matches the cookie domain. 

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

Essentially, you can have a cookie for all subdomains if the domain is listed with the leading "."

If the domain is omitted, although (and therefore implied by the server from the request), this can never be the case because the domain should always have the same match.

Further research identified:

In practice, browsers save the domain specified in the cookie added . (for www.example.com it will store .www.example.com ), so a request to subdomain.www.example.com will also return this cookie. If no domain is specified, a simple domain without one added . will be saved, so the subdomain request will not contain this cookie.