First of all, it is not possible for foo.com
to set a cookie that can be read by bar.com
. Host-only
only protects example.com
cookies from being read by bar.example.com
.
From RFC 6265 regarding setting a cookie and its Domain
attribute:
If the domain-attribute is non-empty:
If the canonicalized request-host does not domain-match the domain-attribute:
Ignore the cookie entirely and abort these steps.
Otherwise:
Set the cookie's host-only-flag to false.
Set the cookie's domain to the domain-attribute.
Otherwise:
Set the cookie's host-only-flag to true.
Set the cookie's domain to the canonicalized request-host.
What this means
The above can be summed up by "Host-only is the default". That is, if Domain
is not specified, the cookie can only be read by the exact domain that has set the cookie. This can be loosened by setting the Domain
attribute when setting a cookie.
For example, if the cookie is set by www.example.com
and the Domain
attribute is not specified, the cookie will be set with domain www.example.com
and the cookie will be a host only cookie.
Another example: If the cookie is set by www.example.com
and the Domain
attribute is specified as example.com
(so the cookie will be sent to foo.example.com
too), the cookie will be set with domain example.com
(or possibly .example.com
by some browsers that use the dot from the previous RFC 2109 to denote not host-only) and the cookie will not be a host only cookie.
Sending of cookies is covered in section 5.4 regarding the when the cookie header is sent by the browser:
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.
So a cookie with domain example.com
and host-only
as false is sent to foo.example.com
. If host-only is true, the example.com
cookie is sent to example.com
only.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…