136891 - External javascript requests aren't passing cookie headers

Status: VERIFIED FIXED

(Core :: Networking: Cookies, defect)

Description

[Thomas Winzig]

We have a page on our site (unfortunately password protected, so I can't show it
to you or my boss would kill me) which contains references to external
javascript files, like this:

<script language="javascript" src="/content/includes/js/browser2.js"></script>

There are 5 of these on this particular page. 

When I access this page in the Mozilla 0.9.9 milestone build, everything works
fine. When I access this in the nightly build I'm using now, I notice the cookie
headers are not being passed on each of those requests.

(The reason I noticed this is because we use a program with IIS called DAF,
which allows us to embed our encrypted login information in cookies -- when
those cookies aren't passed, the browser asks us to login to the site normally.
In this case, the page is displayed, but I get requested to login once it hits
the external javascript file references.)

I checked the logs for our site, and sure enough no cookies are being passed.
Other headers are being passed, though, like HTTP-REFERER.

I noticed this problem a few nightly builds ago, but am just now reporting it.

Comment 1

[Thomas Winzig]

To clarify -- cookies ARE being passed on the normal page requests. They
apparantly are NOT being passed on requests for things within the page. (Well,
for external javascript files, at least.) 

I am pretty sure that cookies ARE being passed on image requests, so I am
guessing it's just external javascript requests that have this problem?

Comment 2

[Darin Fisher]

-> morse, sounds like this might be a cookie blocking issue??

Comment 3

[David Barnes]

I created a test application, but could not recreate the problem. For me, the
cookies were passed when getting an external JavaScript file. For
authentication, I am using the .Net forms authentication system.

Here is the sample page: http://algonquin.tzo.com/authenticate/test.html

The test.html loads an external javascript file using the tag <script
language="javascript" src="javascript.js"></script>

If you try to go to test.html directly, you will be redirected to a login page.
The username/password are test/test. Hit submit and then you will be redirected
to the test.html page.

Everything should load, including the external JavaScript page which has an
alert function. I checked my IIS logs and saw the following:

2002-04-12 04:55:49 127.0.0.1 - 127.0.0.1 80 GET /authenticate/javascript.js -
200 HTTP/1.1 localhost
Mozilla/5.0+(Windows;+U;+Windows+NT+5.0;+en-US;+rv:0.9.9+)+Gecko/20020411
ASPSESSIONIDQGQGQVLC=KACJGKICENMHABJDIEOBFAKK;+.ASPXFORMSAUTH=8B5FF5773DD02B8B244474D33D7620F55C9BFE592695F4847BC11ED5C06B2E39A4613D959EB069169F24223005A22234E0100AB176164F3E3E6C95025D4B6CF9
http://localhost/authenticate/test.html

It appears in this case the cookies were being passed for the external
Javascript - did I do something wrong or different from you?

Comment 4

[Thomas Winzig]

Only a couple things different, but I don't know if they could be causing the
problem. The first difference is the area I encounter the problem on my site
uses Basic Authentication. It looks like you are not using BA for your login.
And the second thing is my javascript files are in a different directory, e.g.:

<script language="javascript" src="/content/includes/js/browser2.js"></script>

instead of

<script language="javascript" src="browser2.js"></script>

I will try to setup a test on my server in a basic authenticated area, and see
if I can reproduce it.

Comment 5

[David Barnes]

One thought - when assigning a cookie, there is an option to set a path, which 
means the cookie is only sent back when requesting files in that directory or 
below. If the external Javascript file is someplace not below that path, then 
Mozilla would not include cookie information in its request for it. Here is a 
web page that talks about cookie paths: 
http://hotwired.lycos.com/webmonkey/98/29/index1a_page13.html?tw=programming

Comment 6

[Thomas Winzig]

Yep, we don't set a path. Keep in mind we weren't having this problem with
Mozilla 0.9.9. It only crept in in the nightly builds following that milestone
release. If I re-install 0.9.9, the problem goes away. So I definitely think a
bug was introduced. Hopefully I will have a demo I can post here later today...

Comment 7

[David Barnes]

I don't know - I added Basic Authentication to the test site - the
username/password is test/test. Plus I put the external javascript in a separate
directory. Same result in IIS:

2002-04-13 00:22:37 127.0.0.1 test 127.0.0.1 80 GET
/externalscript/javascript.js - 200 HTTP/1.1 localhost
Mozilla/5.0+(Windows;+U;+Windows+NT+5.0;+en-US;+rv:0.9.9+)+Gecko/20020411
.ASPXFORMSAUTH=D2A7320E8AC3C94B45F35DC27F35723B6AB57755EA5C01E56FBDBCA48AD668CCAC3E72EA606FD2757E4D89F4F1361A1746FF60056555346760B4879E1379D86C
http://localhost/authenticate/test.html

Comment 8

[Tom True]

I have what may be the same bug.  If  "Enable cookies for the originating web
site only" is set, the cookie that has been set is not sent when retriving
javascript via  SRC.  The main page sets a session id cookie with a path of /, 
but when <script> retrieves /javascript/md5.js, the cookie is _not_ sent to the
server and so a new 'Set-Cookie' sets the session id to a new value.  As a
result, it is impossible to log in.  If I change cookie security to "Enable all
cookies", everything works.  

I've tried using a Windows build from earlier today but still see the problem.
The build was installed in a clean directory but I haven't tested with a new
profile.  I'll try that Monday if not sooner.  I was running this on a Windows
2000 box. Unfortunately, this problem breaks the ability to login to our course
management system.  I've got a log using NSPR_LOG_MODULES=nsHttp:2 which I'll
attach.

Comment 9

[Tom True]

Attachment: Promised log showing failure to send cooke when requesting javascript

This log shows that after / has been requested a cookie is successfully set and
later returned.  It is not returned when either of the two javascripts are
requested and causes a second value to be set for the cookie.	Cookies were
set to be returned only to the same server.

Comment 10

[David Barnes]

I see the same thing when changing cookie preferences to Enable cookies for the
originating web site only

Comment 11

[Thomas Winzig]

Yes! I can also verify that this bug only occurs when "accept cookies from
originating site only" is turned on. If I set it to accept all cookies, then I
no longer find the problem occurring!

Comment 12

[Ray Aspeitia]

Just to confirm, 

I am also seeing this bug in nightly build 2002041711 for Mac OS 9

Comment 13

[Thomas Winzig]

I am no longer experiencing this bug in Mozilla 1.0 RC1. Can anyone else confirm?

Build 2002041711 on Windows XP.

Comment 14

[Thomas Winzig]

Apparantly I spoke too soon. I tried to reproduce this bug twice, same way as
before, and could not. So I assumed it was fixed. But just now I restarted my
system and performed the same actions, and the bug is still in effect. :-(

Comment 15

[Tom True]

You need to watch that Mozilla hasn't cached the script that it needs.  I've had 
most consistent success by clearing the cache before I try to reproduce this.

Comment 16

[Boris Zbarsky [:bzbarsky]]

confirming so this gets some attention...

Comment 17

[Takuo KITAME]

It is appeared also on Linux.

Comment 18

[Michael Alan Dorman]

I was seeing similar behavior, albeit with css style sheets and on Linux.  In
fact, I submitted the bug that Takuo saw in the Debian Bug tracking system.

One thing I noticed that I do not see mentioned:  For cookies sent with
domain=host.dom.ain, the record stored in cookies.txt was stored as
.host.dom.ain.  This is inconsistent with the behavior of 0.9.9, and
inconsistent with what is being sent from the server.

I hope this additional information helps track down the behavior.

Comment 19

[Stephen P. Morse]

> For cookies sent with domain=host.dom.ain, the record stored in cookies.txt
> was stored as .host.dom.ain.

If the value of a domain attribute does not start with a dot, then it is 
in violation of the cookie spec (RFC 2109).  The browser is being kind in adding 
the dot so that it can do the right thing with such an invalid set-cookie 
request.

Comment 20

[David Wheeler]

FWIW, I'm seeing this bug, too. I'm using RC1 on Mac OS X:

Mozilla 1.0 Release Candidate 1
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417

All works fine with cookies enabled, but if I switch to "Enable cookies for the
originating web site only", then cookies are not submitted for an external JS
request.

Thanks!

Comment 21

[nervezilla]

I am experiencing a cookie problem that seems related to this.  As of Mozilla
1.0 RC1 (Win32 version) cookie data is no longer being passed to the server with
document.load().  I sure do miss it......

Comment 22

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Somebody commented in the newsgroups that document.load() no longer passes
cookies either. That is a method on an XML document, visible to JS as well. I do
not have a testcase. 

XMLHttpRequest still seems to send cookies (I have testcases in another bug if
needed).

Comment 23

[Stephen P. Morse]

I'm very confused as to whether we have a test case for this or not.

In the description, Winzig said he could not give us access to his test because 
it was password protected.

In comment 3 Barnes said he created a test case and gave the url for it.  But he 
said that with his test case he was not able to reproduce the problem.

In comment 4 Winzig said he would try to set up a test case that we can use, and 
in comment 6 he said he hoped to have it done "later today" which was April 12.

In comment 8 tdtrue says he has what might be the same bug, but failed to tell 
us how we can reproduce it.

In comment 10 Barnes said that he still could not reproduce the problem with 
his test case, even when he set the cookie preference to be original-server-only 
(at least I think that's what Barnes said in comment 10).

Then in comment 12 Aspeitia said he can reproduce the bug.  But what test case 
is he using?

In comment 17 Kitame said he sees this on linux.  But again I don't know for 
what test case.

In comment 20, Wheeler is seeing the bug too, but again no test case is 
mentioned.

Then in comment 21 and 22, Nervezilla and Toivonen talk about a cookie problem 
with document.load() but I don't know why they believe that has anything to do 
with the bug being reported here.  In any case, they don't give a reproducible 
test case.

So am I missing something here?  Is there a test case that all these people are 
seeing but I'm not finding?  If so, please post the URL for it in the URL field 
of this report, so that I can test it out.  

Comment 24

[Thomas Winzig]

I didn't bother creating a test case, because at the time, David Barnes came
back and said he could reproduce it on his public site if he turned the option
on to only send cookies back to the originating server. But now it appears that
test case page is password protected, so it's not available any more. 

Since I can reproduce this problem every time, I would have no problem creating
a test case, except I don't have access to our web server content areas for a
while. Just create a page with an external javascript reference like this:

<script language="javascript" src="/content/includes/js/browser2.js"></script>

Set your webserver to log the cookie header field in the log. Setup another page
that uses Javascript (or CGI) to set a cookie for testing. Then turn on that
option to only send cookies to the originating server. Load the first page with
the external javascript request in it. Now view your log, and you should see the
test cookie being passed for the first page request, and not on the second
request for the .js file. 

I don't know of an easy way to create a test case to show this.

Comment 25

[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 26

[David Barnes]

Sorry for the confusion. We went back and forth trying various things before
finding the exact problem. Here is a sample case:

http://algonquin.tzo.com/authenticate/

The site requires a cookie before it will give you a page. After you log in, you
will see a page that attempts to load an external javascript file. With "enable
all cookies" it works, with "enable only from web site" it does not load the
javascript. Let me know how it works.

Comment 27

[Peter Trudelle]

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

Comment 28

[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 29

[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 30

[Stephen P. Morse]

And now *really* marking as fixed.

Comment 31

[Tom Everingham]

verified trunk and branch 05/29/02 builds, linux rh6, winNT4, mac osX