134625 - cookies not always being sent when "originating server only" is turned on

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect)

Description

[Martin Dougiamas]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
Gecko/20020330
BuildID:    2002033009

I have cookies set to "Enable cookies for the originating server only".  In one
of my sites (http://moodle.com) I set a cookie with user authentication
information, which is passed with every subsequent request to the site.  After
several requests, the browser appears to stop sending the cookie (causing my
site to redirect the user to the authentication page to log in).

This bug doesn't exist in 0.9.9 - it started happening in every nightly I've
tried since then, including 03/30.

Reproducible: Always
Steps to Reproduce:
1. Set Prefs->Privacy->Cookies to "Enable cookies for originating sites only"
2. Log in using "guest" and "guest".
3. Surf around in the site for a few pages.

Actual Results:  You will eventually be forced out to the login page again.

Expected Results:  Mozilla should have continued sending the cookie.

I've only tested on XP.  If I change my cookie preference from "Enable cookies
for originating sites only" to "Enable all cookies" then this problem does not
occur.

Comment 1

[Juha Luoma]

Perhaps related to this is the problem at the site <http://www.hobbyhall.fi/>.
If you go there with the cookie setting "originating server only", the site
redirects to the error page explaining that cookies are disabled. However,
looking at traffic capture all is coming from and going to the same server but
Mozilla just does not send the cookies that it should send. I'm using 2002032708
on Win2000.

Comment 2

[Martin Dougiamas]

Yes, I agree, I see the same problem on <http://www.hobbyhall.fi/>.  It's
probably a better test case than my original one.

Comment 3

[Robert Thörncrantz]

This is a problem in linux too. 

I first saw it with 0.9.9 for linux, and it's still a problem with 2002040211

Another test case is http://www.bol.se/. A yellow pop-up with a swedish error
message will occur when "originating web site only" is checked, but not with
"enable all cookies"

Comment 4

[Tim Powell]

I'm seeing a similar problem on an internal site with 20020408 win2k. Setting to
enable all cookies works correctly. Netscape 4.x with the same originating
server only setting works fine, as did Mozilla up until recently.

Comment 5

[Stephen P. Morse]

Most likely a dupe of bug 134203.

*** This bug has been marked as a duplicate of 134203 ***

Comment 6

[Juha Luoma]

I can confirm that with build 2002040903 on Win2k both testcases from comment #1
and #3 are now working ok.

Comment 7

[Martin Dougiamas]

I can confirm the test cases from comment #1 and comment #3 now work, but the
original test case in the bug description does NOT work yet with 2002040903 on
XP. Reopening bug.

Comment 8

[brentmh]

I am still seeing this bug on Linux as well

Build ID: 2002041203
1.0.0 branch

Can someone nominate this for mozilla1.0 as well?  

Comment 9

[Klaus Malorny]

I experienced the same behaviour with the request tracker
(http://www.bestpractical.com/) we have installed at our company.

Comment 10

[Philipp Hanes]

I submitted a different bug (bug #137200), but it might be this one.
For me (WinNT and WinME), as of the nightlies *after* 0.9.9 (starting between
the Feb 25th nightly and the Mar 4th one) if I have my settings on "originating
web server only", cookies are not being passed through to included .CSS or .JS
files.  Not sure about images.
Here's some stuff that shows what happens:
http://philipp.virtualave.net/test/mozcookies/
I apologize for the banner ads, but my regular ISP is all messed up at the moment.
if you load "cookme.html" and click on "set a cookie" it'll set a cookie called
"mozcookie".  You may have to reload the page to be able to click on, say,
dynamic-head, which refers to a javascript function defined in a .js file
included in the head (I wasn't sure if this made a difference with head/body at
the time).  The .txt versions show you the source.  If you go straight to the
.js files, you'll see that it will tell you about cookies, while the popup
indicates that they *don't* know about any cookies at all.
I'm sure there's a better way of demonstrating the problem, but it's all I could
come up with at the time.

Comment 11

[Hrunting Johnson]

I'm also seeing this latest problem with JavaScript files.  If I point Mozilla 
directly to the JavaScript file, it sends the cookie fine, but when Mozilla 
tries to load the JavaScript file through a <script /> src attribute, it 
doesn't send the cookie.  My cookie usage is for authentication, so it's not as 
if the JS isn't able to access the cookie information; the browser really isn't 
sending it.

Comment 12

[Juha Luoma]

I can confirm the the previous comment (comment #11). I verified this with
traffic capture. I'm now using 2002042106 build from 1.0.0 branch. I really
liked this to be fixed in final 1.0.

Comment 13

[lode leroy]

I have found the same problem.

My initial guess was that my problem had to do with the fact that there was a
'port' appended to the name of the site. (my port is not 80).

build=2002041711 (RC1), win32/NT4,  web server = ATG Dynamo 5.1.1p3

Comment 14

[Philipp Hanes]

Here's the problem:
It looks like Mozilla does not consider "current server" to be an originating
server.
Try replacing your relative, or absolute-from-the-top-of-this-server URLs with
fully-qualified-with-protocol-and-host-etc URLs.  Looks like the cookies get
sent then.
e.g.  instead of saying:
   <script src="/scripts/myjscript.js">
use:
   <script src="http://myserver.mydomain.my/scripts/myjscript.js">
the server you use has to be exactly what you see in the Location bar on the
page itself.  It'll get the cookies.

Comment 15

[Jeffrey Baker]

This bug too.  Just so everyone knows what we are talking about, Mozilla will
send a Cookie header in the request for a page, but subsequent requests for
scripts and style sheets will NOT include the Cookie header, even though the
host is the same.  This is a serious regression of HTTP functionality. 
Nominating for 1.0

Comment 16

[Martin Dougiamas]

Not always that simple.  I tried to create a simplest test case to show this bug
but frustratingly it works fine. There's some other factor involved. You can
bang on my new test case here:  http://old.moodle.com/mozilla/

Comment 17

[Stephen P. Morse]

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.

Comment 18

[Rolf Grossmann]

Works for me, thank you very much. I can now use request tracker (like  Klaus
Malorny mentioned in comment 9), which previously triggered the bug.

Comment 19

[Martin Dougiamas]

I can't build, but if someone can provide me with a binary (Win32, Linux or OSX)
I can do any amount of testing.

Comment 20

[Peter Trudelle]

Nav triage team needs info: Does this happen on any top sites? What is the
impact on target users?

Comment 21

[Stephen P. Morse]

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 probably being one of them.

Comment 22

[Martin Dougiamas]

I just exhaustively tested the original report (moodle.com) using trunk build
2002051408 and the problem has gone.  I can not get it to fail.  Yay!  Hopefully
 the patch for bug 137079 will make it into 1.0.

Comment 23

[Stephen P. Morse]

Being marked fixed since the patch for 137079 is checked in on trunk.  However 
it is not yet fixed on the branch.

Comment 24

[Tom Everingham]

patch has been checked in to branch and this is working

verified branch, 05/23/02 builds