Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Add support for the global PAC functions

NEW
Unassigned

Status

()

Toolkit
WebExtensions: Request Handling
P2
normal
4 months ago
2 days ago

People

(Reporter: mattw, Unassigned)

Tracking

(Blocks: 1 bug, {dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [proxy] triaged)

(Reporter)

Description

4 months ago
See http://findproxyforurl.com/pac-functions/ for details about PAC functions.

For more information about the Proxy API, see the design document: https://docs.google.com/document/d/1W45o5X2bFRPrTaQDFp9IzTJ8njCVfEgyENS7i2owaUI/edit?usp=sharing
Keywords: dev-doc-needed
These implementations can be used in the WebExtensions Proxy API:
https://dxr.mozilla.org/mozilla/source/netwerk/base/src/nsProxyAutoConfig.js

Comment 2

27 days ago
Is nsProxyAutoConfig.js available in FF55+?
Can it be imported into nsProxyAutoConfig.js?
What about ProxyAutoConfig.cpp?

Comment 3

24 days ago
I have started to write the PAC functions. Once finished, I will pass it Matthew for testing and implementation.

Comment 4

24 days ago
re: DNS

nsIProtocolProxyService already has the DNS methods. The resolve() is deprecated and asyncResolve() complicates the PAC dnsResolve(host) function. 

ProxyAutoConfig.cpp uses C++ for dnsResolve(host) and myIpAddress(). 


There are other PAC functions also that depend on dnsResolve() (IP based) and they are all synchronous eg:

isInNet()
isResolvable()
myIpAddress()


Any suggestions?


PS. I have prepared the rest (based on ProxyAutoConfig.cpp with some modifications/updates)

Comment 5

23 days ago
I have written dnsResolve() as asynchronous asyncDnsResolve() however, the function would no longer match standard PAC functions and anyone using it will have to write their code to suit a asynchronous result with callback.
(Reporter)

Comment 6

23 days ago
If you look at https://reviewboard.mozilla.org/r/73182/diff/3/, I originally had a partial implementation of the proxy globals - in there you can see I have an implementation of dnsResolve, which if it works, I believe is synchronous. I ended up removing them from that bug because the patch was getting too large, and I'd also really like to have unit tests for the functions.

Comment 7

23 days ago
resolve() has been deprecated since Gecko 18
> This method has been removed in Firefox 18. Use resolveAsync instead
ref: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProtocolProxyService


No mention here but I am guessing it is removed and the MDN hasn't been updated.
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDNSService

What I was working on ....

ext-proxy.js already imports: ProxyScriptContext.jsm

ProxyScriptContext.jsm also imports:

XPCOMUtils.defineLazyServiceGetter(this, "ProxyService",
                                   "@mozilla.org/network/protocol-proxy-service;1",
                                   "nsIProtocolProxyService");


Therefore there is already access to nsIProtocolProxyService

I have prepared all PAC functions that don't need dnsresolve() as pure JavaScript code.
I have also written the ones that need DNS, as both sync and async functions.

These are in plain JS and not prepared as API.

The discrepancy on MDN regarding isInNet() has to be decided on since otherwise isInNet()can be done with pure JavaScript but the way Firefox has it with built-in dnsResolve(), requires rewriting it as async

https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_(PAC)_file#isInNet()

Comment 8

23 days ago
re: isInNet()

Firefox ProxyAutoConfig.cpp impemented isInNet() with built-in dnsResolve()

Oracle Java also does the same .
https://docs.oracle.com/cd/E19575-01/821-0053/adyrv/index.html


PAC Functions states:
https://findproxyforurl.com/pac-functions/

> isInNet
> This function evaluates the IP address of a hostname, and if within a specified subnet returns true. If a hostname is passed the function will resolve the hostname to an IP address.

However, the examples show that dnsResolve() have been passed as a separate function which shows isInNet() in itself does not resolve the DNS.

> if (isInNet(dnsResolve(host), "172.16.0.0", "255.240.0.0"))

A decision has to be made on the proper implementation.
These functions can be added to the scope of the PAC by defining them on |this.sandbox| in ProxyScriptContext.jsm.

To see how its done at the browser scope (not WebExtensions):

https://dxr.mozilla.org/mozilla/source/netwerk/base/src/nsProxyAutoConfig.js#84
Changing to P2 because some of these functions can be implemented by addon authors themselves in their addon's FindProxyForURL() module. Copy Javascript implementations from https://dxr.mozilla.org/mozilla/source/netwerk/base/src/nsProxyAutoConfig.js to your addon. Ones related to dns lookups cannot be implemented that way.

@erosman, concerning dnsResolve():

bug 887995 added AsyncResolve2(), which does asynchronous DNS resolution, but according to John-Galt the entire FindProxyForURL() is synchronous and therefore can't do asynchronous DNS resolution in any way.
Priority: -- → P3
Priority: P3 → P2

Comment 11

3 days ago
Is there any chance of providing any form of Domain to IP conversion?

It can be fresh DNS query or even grabbing the IP from the Firefox DNS cache.
Domain based proxy selection, while mostly adequate, does not cover all the required possibilities.

The PAC implementation (direct via Network - Connections -  Settings) seems to use a C++ synchronous dnsResolve.

As mentioned in comment 7, there is API access to asyncResolve() (and I have already prepared the code) but that may or may not work in WebExtension implementation of Proxy API.

It appears that the WebExtension Proxy API is also synchronous. Is there any way to pass the IP to ProxyScriptContext.jsm?
> Is there any chance of providing any form of Domain to IP conversion? ... Is there any way to pass the IP to ProxyScriptContext.jsm?

I think you should open a new bug

Comment 13

2 days ago
> I think you should open a new bug

Done ... bug 1382684
You need to log in before you can comment on or make changes to this bug.