bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Cookies are not being past to the server when getting <LINK> href

VERIFIED FIXED in mozilla1.0



Networking: Cookies
16 years ago
16 years ago


(Reporter: Marc Loiselle, Assigned: Stephen P. Morse)


Windows 2000

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [need info])



16 years ago
Cookies are no longer being sent when getting the href of a LINK tag.  I know
that the cookies exist since they appear in the Cookie Manager. 

I detected this because I wrote a java servlet that generates an html page (this
sets a cookie JSESSIONID) with LINK tag that has the same servlet as the href. 
When the LINK is loaded the servlet detects that no session is present since
there no cookies and then sets JSESSIONID.

Buildid 2002030703.

This was NOT a problem with Buildid 2002022703.

Comment 1

16 years ago
I'll need a reproducible test case here.  Also, do you have your 
cookie-acceptance pref set to block third-party cookies?

Comment 2

16 years ago
It is hard to provide a test case since it not caused by the html.
I have a servlet (http://localhost/vch/servlet/Main?act=main ) that generates
html with the following link tag in it.  

<link rel="stylesheet" href="?act=getStyleSheet&styleSheet=ratedg.css">

I can provide a publicly accessible web site if you think that would help.

Yes I do have the block third-party cookies perference set.  If I change the
cookie pref to accept all cookies, the cookies are sent.

What is considered a third-party cookie?

Comment 3

16 years ago
OK, that explains it.  Third-party cookie blocking has not worked in a long time 
and it was simply being ignored.  Last week I created the appropriate 
infrastructure so that the cookie module could be notified appropriately.  For 
each path leading to the cookie manager I had to make a decision about how to 
interpret third-party (redirects for example are not considered third-party).  
It's possible that the wrong decision was made for the path involving links, but 
I would need to do further investigation in order to know for sure.

Yes, please do provide a publicly available website so that I can test this out 

Comment 4

16 years ago
I created a minimal test case at

The servlet generates a link tag and sets a cookie JSESSIONID.  The url of the
link tag is a servlet that generates some css ( body { color: red } if cookie is
found or body { color: black } if cookie is not found ).  Hope that helps.

Comment 5

16 years ago
I'm observing the exact same thing, this time in a mod_perl environment. Cookies
don't get sent for LINKed stylesheets (also dynamically generated) which wreaks
havoc upoc session management (as the stylesheet creates new session and
overrides the old one)

Comment 6

16 years ago
win2k and linux x86 build 2002041711 does not send cookie when right clicking
"save link as"

Private https so not public test case.  


Log in to secure site requiring cookies for session management.  No cookies
results in redirect to a how to turn on cookies page.  Opening link in new tab
presents security warning for entering secure web site.  After dismissing, web
page opens normally - cookie is being passed.

Right clicking ("save link as") trying to  save .asc file (ascii text with page
breaks) on a secure page results in redirect to a "your cookies are turned off"
page getting saved instead of the requested file.

Cookies are enabled for originating web sites only and warn before saving but
remembered this particular site to accept cookies.

Comment 7

16 years ago
The test case, http://www.phoenixcsi.com/vch/servlet/Controller/CookieTest, is 
not valid.  I get the "Not Found" message when I try to go there.

Could you please post another test case.  Thanks.

Comment 8

16 years ago
Although the symptoms are different, the patch just posted to bug 137079 will 
probably fix this bug as well.  Can someone who can reproduce this bug please 
apply that patch and see if it takes care of this problem.
Ever confirmed: true
Keywords: mozilla1.0, nsbeta1
Target Milestone: --- → mozilla1.0

Comment 10

16 years ago
Nav triage team needs info: what is the impact of this bug on target users?
Whiteboard: [need info]

Comment 11

16 years ago
The impact of this one instance is small.  But see the discussion in bug 137079.  
Although the symptoms there are different, the fix for that bug will fix many 
other bugs as well, this being one of them.

Comment 12

16 years ago
wfm with trunk build 2002051421 on linux.


16 years ago
Depends on: 137079
Keywords: mozilla1.0, nsbeta1

Comment 13

16 years ago
Being marked fixed since the patch for 137079 is checked in on trunk.  However 
it is not yet fixed on the branch.
Last Resolved: 16 years ago
Resolution: --- → FIXED


16 years ago
Keywords: fixed1.0.0

Comment 14

16 years ago
verified per reporters comments

Comment 15

16 years ago
verified branch - 05/28/02 linux rh6, mac osX, winNT4
Keywords: verified1.0.0
You need to log in before you can comment on or make changes to this bug.