Cookies for not recognized for




9 years ago
9 years ago


(Reporter: glamd, Unassigned)


Firefox Tracking Flags

(Not tracked)




9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20090729 Firefox/3.5.2

When a cookie for "" is set, and the user opens, the cookie is not regognized as being from that domain. Actually, the cookie for '' has 'host' in the cookie preview, while the '' has 'domain' instead of 'host'. 
In previous versions this was working fine.

Reproducible: Always

Steps to Reproduce:
1. Open
2. Login (i.e. set a cookie for '')
3. Nagivate to
Actual Results:  
the cookie is not recognized, and you are not logged in. As if these are two different pages.

Expected Results:  
The user should appear to be logged (i.e. the cookie recognized as belonging to that domain)

Comment 1

9 years ago
That depends on the actual website, in particular the 'domain' parameter in the Set-Cookie or Set-Cookie2 header that is setting the cookie. The default would be readable on the level, but the reverse is not true. See RFC 2965 : pay partiulcr attention to section 3.2.2

Also, it's important to know which top-level domain is used (.com ?) - a TLD isn't always the last word (for instance in case of it's

Comment 2

9 years ago
The domain in my specific case is ".nl"
The fact I reported it as a bug immediately after I saw it, was because I'm the developer of the site, and I made it work fine around 2-3 weeks ago - on FF, IE, Opera and Chrome. And it worked in all browsers. Now after the last (or the one before it) update, FireFox is the only of the 4 that behaves not the way it is expected.
I checked on my FireFox 2 on my old laptop - it is fine there, too.
The site in question is "". Try logging in with testtest / testtest on , and then add "www" to the URL. The cookie in question is the session cookie (JSESSIONID)

Comment 3

9 years ago
You're using a header like this (on :

Set-Cookie: JSESSIONID=F33F9B6D42E07C3E72E985E7836CAC0B; Path=/

There's no domain parameter, so it defaults to Because there is no dot at the beginning of effective request-host, the default domain can only domain-match itself (RFC 2965, section 3.3.1)

I think it would have worked if you used as the domain parameter, like explained in bug 465507. I'm not sure why it stopped working in the update, maybe because of bug 421494.

Note that is a *different* site than, despite any possible CNAME redirect.

Comment 4

9 years ago
Yes, and are different sites, that's why on login I'm explicitely getting the existing JSESSIONID cookie and set its domain to "", and send it to response. I will further investigate my code, but my suspicion about this thing working in previous versions, and in other browsers, is still lurking. :)

Comment 5

9 years ago
Hmm, the problem is not what I initially thought, so you I'm marking it resolved.
The real issue was that there were two JSESSIONID cookies persisting (and probably because of the session manager they wouldn't go away even though they are to expire when the browser if closed). I removed all the cookies manually, reattempted login, and it worked.
Last Resolved: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.