Closed Bug 638218 Opened 9 years ago Closed 9 years ago

Asynchronous policy-uri fetching causes connection problems when using NTLM proxy

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0
Tracking Status
blocking2.0 --- final+

People

(Reporter: bsterne, Assigned: mayhemer)

References

Details

(Whiteboard: [hardblocker])

Attachments

(1 file)

Spin-off of bug 638179.

Bug 558431 made policy-uri fetching asynchronous.  It was backed out because it causes problems connecting to sites using a CSP policy-uri through an authenticated NTLM proxy.

The async fetching of the policy suspends the document channel while it makes an asynchronous request for the policy which resumes the document upon returning.  In the case of the NTLM proxy, the document channel never gets resumed.
Brandon, we verified that the channel never get resumed?  Do you reach the line where you call resume() on the channel in the CSP code?
It looks like CSP calls resume() when it gets OnStopRequest for the CSP file, and that it does this to the mChannel of the nsDocument, right?  Once we're at that point, that channel should not be changing.  So we really need to check whether we reach that resume() call, so we can tell whether the problem is in resuming or in getting to that point to start with.
(In reply to comment #1)
> Brandon, we verified that the channel never get resumed?  Do you reach the line
> where you call resume() on the channel in the CSP code?

Unfortunately, my gdb skills aren't super-awesome and I'm not sure how to step through code in JavaScript components.  Any tips on how I could do that?
Honza's seems to be onto something.  See bug 638179 comment 29.
I am just investigating it.
Assignee: nobody → honzab.moz
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "'[JavaScript Error: "selfURI is null" {file: "file:///D:/mozilla/mozilla-central/_obj-browser-debug/dist/bin/components/contentSecurity
Policy.js" line: 234}]' when calling method: [nsIStreamListener::onStopRequest]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"
 location: "<unknown>"  data: yes]
************************************************************

Occurs here: http://hg.mozilla.org/mozilla-central/annotate/a9058439d985/content/base/src/contentSecurityPolicy.js#l234

Called from here: http://hg.mozilla.org/mozilla-central/annotate/a9058439d985/content/base/src/CSPUtils.jsm#l165

I believe the 'null' as a second argument is extra?
Attached patch v1Splinter Review
This fixes the hang for me.
Attachment #516457 - Flags: review?(bsterne)
Duplicate of this bug: 638179
Attachment #516457 - Flags: review?(bsterne) → review?(dveditz)
blocking2.0: --- → ?
blocking2.0: ? → final+
Whiteboard: [hardblocker]
Comment on attachment 516457 [details] [diff] [review]
v1

r=dveditz for fixing the stop-ship bug by eliminating the extra null arg.

both calls have an extra this._docRequest argument while the function defines only 2 args. Internal to the function it references "this._docRequest"--not sure that's the same _docRequest. Please file a bug on investigating cleaning this up, but it doesn't need to hold up the release.

Honza: bsterne is running for the train. If you can land this I bet drivers would be happy. Otherwise bsterne will be back online later this evening.
Attachment #516457 - Flags: review?(dveditz) → review+
Whiteboard: [hardblocker] → [hardblocker][has patch]
(In reply to comment #9)
> both calls have an extra this._docRequest argument while the function defines
> only 2 args. Internal to the function it references "this._docRequest"--not
> sure that's the same _docRequest. Please file a bug on investigating cleaning
> this up, but it doesn't need to hold up the release.

Filed bug 638320 for this.
http://hg.mozilla.org/mozilla-central/rev/2a993660946f
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [hardblocker][has patch] → [hardblocker]
Target Milestone: --- → mozilla2.0
Duplicate of this bug: 638395
Summary: Asynchronous policy-uri fetching causes connection problems when using NTML proxy → Asynchronous policy-uri fetching causes connection problems when using NTLM proxy
You need to log in before you can comment on or make changes to this bug.