Duplicate cookies, changes to cookie rather than replacing cause it to be duplicated




Networking: Cookies
13 years ago
13 years ago


(Reporter: vford, Assigned: Darin Fisher)


1.7 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:needinfo])


(1 attachment)



13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Similar to bug 223469

Creating a site using JBoss/Tomcat 4.0.2 that requires making changes to the
JSESSIONID cookie for failover and session management. Rather than replacing the
value a duplicate cookie is created. Worse yet the cookies can't be expired
either  properly either. It appears that all cookies are held regardless of
updates from the server until the session ends (closing the browser)

This poses major issues for site designers since there should only be one cookie
from the same domain, cookie path and ID. Most session cookies by sites are only
written once but this could pose a security issue, since when a user logs out of
a site the cookie should be deleted but in this case cookie isn't removed until
after the browser is closed. For most home users not a big issue but for those
working in other situations this could expose information.

Reproducible: Always

Steps to Reproduce:
1.go to a site that sets cookie
2.go to a jsp/servlet page that changes the cookie value
Actual Results:  
Duplicate cookies created with the same ID.

Expected Results:  
One cookie updated.


13 years ago
Assignee: nobody → darin
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
Version: unspecified → 1.7 Branch
This doesn't need to be security sensitive (but thanks for erring on the side of

This is not similar to bug 223469, this *is* bug 223469. Just as that was WFM so
will this unless you can provide more details on how to reproduce it. An example

By specifying a jsp server app I assume you're talking about setting the cookies
using HTTP headers.

If you can't find a public site that exhibits this problem (I assume you're not
going to let us poke at the server you're building or you'd have given us the
address) please capture some logging data for us.


Probably logging just the cookie data might be enough to start, or cookie and

By any chance does your page set document.domain? that might be confusing
things... (It shouldn't, but I'd like to rule it out or explicitly check into it
if you're using it).
Group: security
Whiteboard: [sg:needinfo]
Reporter, can you answer the questions in comment 1?
I can reproduce this problem but the URL I cannot put here. Because it's not global web site(bugzilla).

I could see two cookies that names are same. But these third field name(caption?) on the cookie viewer on Fx1.6a were different that are 'domain' and 'host'.
Ever confirmed: true
OS: Linux → All
Er.. domain and host cookies are different things.  So what you see is correct.  If that's all there is to this bug, it's invalid.
(In reply to comment #5)
> Er.. domain and host cookies are different things.  So what you see is correct.
>  If that's all there is to this bug, it's invalid.

But by this duplicated, the bugzilla cannot manage user log-in session. I deleted the cookie that has 'host', and I log-in to the bugzilla, another cookie that has 'domain' are overwritten to 'host' by the bugzilla...

Comment 7

13 years ago
If you are having problems with a particular Bugzilla installation setting the wrong kind of cookies, please seek help with the configuration, or file a bug within the Bugzilla product providing the relevant configuration information and details on exactly what cookies are being set, etc..
Umm... I don't have enough knowledge for cookie spec...
I'll check cookie spec and check netwerk/cookie code.
If I found bugzilla's bug, I'll report.

Well, this got confirmed for no reason, there's no response from reporter... Marking invalid until someone has some hard data actually showing a problem in Mozilla.
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.