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

Status: RESOLVED FIXED

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

Description

[Brandon Sterne (:bsterne)]

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.

Comment 1

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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?

Comment 2

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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.

Comment 3

[Brandon Sterne (:bsterne)]

(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?

Comment 4

[Brandon Sterne (:bsterne)]

Honza's seems to be onto something.  See bug 638179 comment 29.

Comment 5

[Honza Bambas (:mayhemer)]

I am just investigating it.

Comment 6

[Honza Bambas (:mayhemer)]

************************************************************
* 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?

Comment 7

[Honza Bambas (:mayhemer)]

Attachment: v1

This fixes the hang for me.

Comment 9

[Daniel Veditz [:dveditz]]

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.

Comment 10

[Brandon Sterne (:bsterne)]

(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.

Comment 11

[:ehsan akhgari]

http://hg.mozilla.org/mozilla-central/rev/2a993660946f