On Tue, Mar 11, 2014 at 05:22:37PM -0400, Mark Smith wrote: > On 3/10/14, 11:23 PM, David Fifield wrote: > >I started trying to write a Firefox extension that makes HTTP requests > >outside of the proxy settings. I have one that works in Iceweasel 24.3 > >and does the Host header trick used by the transport. However it doesn't > >work in Tor Browser, and I'm looking for some insight as to why it might > >be so. > > > >The source code of the extension is in the "firefox" directory of > > git clone -b extension https://www.bamsoftware.com/git/meek.git > >Instructions on how to try it are: > >https://developer.mozilla.org/en-US/docs/Building_an_Extension#Test. > >I also pasted the important JavaScript code at the end of this message. > > I looked at this for a few minutes but ran out of time for today. > > When I dump aStatus in your onStopRequest function, I get 2152398890 > which is 0x804B002A which is NS_ERROR_UNKNOWN_PROXY_HOST (see > https://developer.mozilla.org/en-US/docs/Table_Of_Errors). > > I am not sure what that means but it sounds interesting.
Thanks for finding this clue. It appears to me that the critical difference is in the network.proxy.socks_remote_dns setting. My Iceweasel had it false and Tor Browser had it true. If it make it true in Iceweasel, the extension fails; if I make it false in Tor Browser, the extension succeeds. I'll see if there's a way to make it work with socks_remote_dns=true. The NS_ERROR_UNKNOWN_PROXY_HOST was coming from the "" hostname passed to newProxyInfo. If I change it to "127.0.0.1", I instead get the error 0x804b0048 NS_ERROR_PROXY_CONNECTION_REFUSED, and I see that Firefox is actually trying to connect to 127.0.0.1, despite that a "direct" proxy type is in use. David Fifield _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
