From:  Mark Hammond <mhammond@skippinet.com.au>
Date:  22 Aug 2013 15:17:46 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.network
Subject:  

Re: Forcing every request from a docShell to use LOAD_ANONYMOUS

NNTP-Posting-Host:  120.148.147.96

On 21/08/2013 2:03 AM, Boris Zbarsky wrote:
> On 8/20/13 2:26 AM, Mark Hammond wrote:
>> I experimented a little with this, and it (almost) works.  I initially
>> did:
>>
>>    docShell.loadGroup.defaultLoadRequest.loadFlags |=
>> Ci.nsIChannel.LOAD_ANONYMOUS;
>
> What you want is a flag you set on the docshell which causes it to set
> the LOAD_ANONYMOUS flag on the requests it makes (like Brian suggested
> eariler in this thread).

Ah, sorry, I misunderstood - I thought you meant content should tweak 
the flags on the default load request.

I played a little more with this, and it *almost* works fine.  The 
problem I have at the moment is, I think, due to speculative connections.

In my use-case, we often request a speculative connection on the URL we 
care about just before we have the "anonymous" docShell perform the 
actual connection.  The speculative connection is done by a mouseover 
event on about:newtab in anticipation of the user clicking on a 
thumbnail rather than as an attempt to speed up the connection made by 
the "anonymous" docShell.

What I believe is happening is that this speculative connection is being 
reused for the connection made by the "anonymous" docShell, and as a 
result mCaps on the transport isn't getting the NS_HTTP_LOAD_ANONYMOUS 
flag, which in turn means the nsNSSSocketInfo for the request doesn't 
get the nsISocketProvider::ANONYMOUS_CONNECT flag, which in turn doesn't 
suppress the SSL certificate prompt for the request.

I'm having trouble catching this case in the debugger, and also in 
following the logic that reuses the speculative connections, so I'm 
still not sure about this - but printf debugging makes me relatively 
confident the problem is along these lines.

Does that sound likely?  If so, any pointers on where I should be 
looking to diagnose this further?

Thanks,

Mark