144988 - Why is FirstURL null at times when it seems that it should not be

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect)

Description

[Michael Sinz]

As seen in bug 137079 and bug 134203 (and related bugs) the FirstURL as passed
to the cookies system (and available elsewhere) is sometimes null when it should
not be.

For bug 134203, the root cause of the problem was found (a redirect) but for bug
137079, it was easier (and safer given the fact we were at 1.0 RC) to work
around the failure of FirstURL by looking at some other structures for a simular
(but not as correct/strict?) value.

We should look at the root causes and make sure that the FirstURL (the
nsIHttpChannel DocumentURI) is set correctly/is not null.

This is important as other security measures may well be broken or working
around this fact (I have not had the time to review the code as to this).  It is
obvious from the cookie problems that at least the cookies depended on this
working and it is not working well enough.  (I can imagine Java and JavaScript
scurity issues depending on this value, but I don't know that)

Even if it was/is only the cookies that are affected, the correct fix is to find
out where and why the DocumentURI is null and fix that.

For example, the fix for bug 134203 was to correctly set up the document URI in
the new nsIHttpChannel object rather than letting it remain null in the case of
a redirect of a top document.

Putting an assert as to nsIHttpChannel.GetDocumentURI() resulting in null is
maybe a bit overkill, but at least logging that (and who called it) would be a
good first start.

Comment 1

[Darin Fisher]

-> default owner

Comment 2

[Patrick McManus [:mcmanus]]

-etimedout