137200 - save as webpage-complete saves the wrong CSS and JavaScript files

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect)

Description

[Philipp Hanes]

Using nightly builds starting right after the 0.9.9 release, the web site I work
on started exhibiting the following behavior:
Seemingly every instance of the style sheet (included via <LINK> tag) and
javascript files (using <script src=foo.js>) is our login page instead.

It's an SSL site, and authenticates using a tool called "siteminder" if that's
of relevance.  This does not happen when reaching the same pages though a
non-secure means.

This is visible both within the page's behavior (any styles not declared inline
on the pages or on the login page are not rendered as such, and references to
javascript funcitons in the included files fail to find any such function), and
when doing a Save Page As -> Webpage, complete (the non-image _files saved are
all copies of this one page).

I can't offer a direct link so others can look at it, since it's a secure (and
expensive) site, but I have enough control over the development environment that
I can try out anything you suggest.

Some more info:  when I just paste a reference to the URL itself into the
location bar, I do always get the correct file.  But it's not using that in the
pages, or saving them.
The files, when saved from the SSL site, all get the extension ".html", while
when saved from the not-secure, not-proxied server, are saved as .css or .js as
appropriate.

It's not clear to me if the .js files always have this happen to them, but so
far it's for *all* CSS files we use.

Comment 1

[Philipp Hanes]

I don't know if this helps narrow it down, but the behavior started somewhere
between the Feb 25th nightly and the Mar 4th one.  I don't have any of the ones
in between, so I can't offer finer grained resolution.

Comment 2

[Adam Lock]

This could be a problem with the mime type your secure server is spitting out,
or with authentication. If the https urls are authenticated somehow its possible
that your receiving back some kind of access denied html.

Can you check the contents of the css and js to see what is actually being saved?

Comment 3

[Philipp Hanes]

What's being saved is a completely legitimate but wrong page from the site. 
It's one that would have been seen previously, as the login page.
The trouble is, when I access the URLs directly, everything looks fine, I see
the CSS file displayed in my browser.  But when I save a page that refers to
that same CSS file, it doesn't save it, instead it saves a copy of our login page.
I believe all the authentication is based on cookies.
Mime type is correct when viewed directly (but then, it looks fine then anyway).
 Perhaps it's not correct when requested/received from inside a page?

Comment 4

[Adam Lock]

In other words, this sounds like an authentication issue. The persist object is
opening data streams without proper authentication and is being redirected to
the login screen which is text/html. This causes the login data to save to the
file (even if its meant to be css, js) and with an .html extension.

I need to know for sure how authentication is done. I'm not to familiar with
https and how it keeps track of where you are in a site with regards to this
sort of thing.

Comment 5

[Philipp Hanes]

In that case it probably is something to do with cookies.  You will be kicked to
the login page (which is itself https) if you don't have a valid cookie (or
more) of ours.  If the requests don't have the same cookies as the page itself,
they'll be redirected.  But since the "main" pages do it right, it's not
interfering with going from page to page, since nothing in the main context is
being modified.  (I hope the words I'm using are making sense... I think I
understand what is happening, at least).
I have no reason to believe regular SSL requests would be having a problem with
this.  I'll try some things with cookies on a non-secure site to see if they
make it through to .js and .css files.

Comment 6

[Philipp Hanes]

Okay, it looks like cookies are definitely not being passed in the requests for
the javascript files (this was the easiest to test).
Now that I look at this again, chances are all our images would be broken as
well, except we explicitly exempt them from having to have the cookie in the
request.
So this bug is now hideously misnamed, I'm sorry.  I can't find another bug that
mentions this, though.
Here's some stuff that shows what happens (on a non-secure site, too):
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.
Is this still the right forum for this problem?

Comment 7

[Philipp Hanes]

This may be related to or a dupe of bug #134625
Having searched based on why I know now, I see that this only happens when I set
my cookie accepting preferences to "originating web server only".
I will add a comment to that bug, too.

Comment 8

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

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

[benc]

Philipp, can you tell us if this is working for you on Mozilla 1.3f and Netscape
7.02?

Comment 11

[Philipp Hanes]

Looks okay on Mozilla 1.3.
I don't know when the last time was this was a problem, actually.
The fix for bug #137079 must have done the trick.