223027 - Mozilla's treatment of domain cookies differs from IE's

Status: RESOLVED DUPLICATE of bug 151903

(Core :: Networking: Cookies, defect)

Description

[Dan M]

Discovered while investigating bug 222343, may be the same as long-dead bug
28956 or a duplicate of that, bug 31401. But the intent of this bug is different
from those latter two. Related to bug 217179.

In Mozilla, a host cookie (that is, a cookie without an explicit domain) is not
visible from a subdomain. In IE, that cookie is visible from a subdomain. So
(and sadly, I can't provide a test case; you'll have to trust me or come up with
your own :-))

visit http://b.com and set cookie1=value and cookie2=value;domain=.b.com
then visit http://a.b.com. In IE both cookies are visible from the subdomain. In
Mozilla only cookie2 is visible. For a morass of detail see bug 222343 comment
7. (And note that neither browser is particular about the leading dot in the
domain specification; a flaunting of the spec implemented by all browsers as a
tip of the hat to standard practice.)

I understand this is pretty much a known issue. We believe we're interpreting
the spec, RFC2109, more faithfully. But I find that spec rather imprecisely
written in the details and I think the correct interpretation is questionable.
Worse, I worry that it could mean a family of sites designed for use with IE,
and what site isn't these days, won't work correctly with Mozilla.

Comment 1

[Mike Connor [:mconnor]]

so did anyone (I'm looking at dwitte here :) really look this over and decide
how we want to deal with this?  There are similar bugs wrt using IE's
interpretation for compatibility reasons.  (i.e. the amiga.org bug)

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

If IE really sends cookies without a domain attribute to all the subdomains it
doesn't just allows stuff that the rfc disallows (like setting domain=foo.com),
but plainly violates the spec.

"(So, x.y.com domain-matches .y.com but not y.com.)"
"Domain Defaults to the request-host. (Note that there is no dot at the
beginning of request-host.)"

I interpret that as: if no domain attribute is given, only send the cookie to
the current host. Hence the name host-cookie.

I admit, it is not easy to find, but it is quite clear. And i think with good
reason. geocities.com doesn't want the cookies for their login pages spread all
around *.geocities.com.

Comment 3

[Darin Fisher]

-> default owner

Comment 4

[[e-mail]]

dupe of the amiga.org bug, which i wontfixed because i think host cookies have a definite use in practice and i wouldn't want to see them go. if anyone has arguments for why we should drop support for host-only cookies, please do speak up in that bug.