Inconsistency: proxy API

[ameshkov]

This topic was discussed during the WECG in-person meeting.

First of all, proxy extensions is one of the most popular extensions category on both CWS and Mozilla add-ons store with hundreds of popular extensions available.

Both Chrome and Firefox provide proxy API which are very different. Firefox API is based on the proxy.onRequest callback and it is more powerful, but it goes against Chrome’s approach of getting rid of blocking callbacks. Implementing Chrome's interface would allow Firefox to benefit from having more extensions available that use non-blocking API.

Links to the documentation

• Firefox
• Chrome

Chrome API example

var config = {
  mode: "fixed_servers",
  rules: {
    proxyForHttp: {
      scheme: "socks5",
      host: "1.2.3.4"
    },
    bypassList: ["foobar.com"]
  }
};
chrome.proxy.settings.set(
  {value: config, scope: 'regular'},
  function() {}
);

Firefox API example

let proxySettings = {
  proxyType: "manual",
  http: "http://proxy.org:8080",
  socksVersion: 4,
  passthrough: ".example.org",
};

browser.proxy.settings.set({ value: proxySettings });

Notable differences

• Firefox proxy API does not allow configuring a PAC file.
• Firefox proxy.settings API requires private browsing window access.

Off-topic about `inclusionList`

inclusionList

In addition to that (I may need to open a separate issue or just open it in Chrome's bug tracker). Currently, we are forced to use an auto-generated PAC script in Chrome as the current API lacks the ability to configure an "inclusion list". PAC script generation is far from ideal and prone to errors so I suggest adding a new inclusionList field to ProxyRules.

If inclusionList is not empty then requests to the hostname should only be sent over the proxy when that hostname is in the inclusionList. inclusionList should support the same syntax as bypassList.

Pseudo-code for the requested logic:

function shouldProxyRequest(request) {
    if (inclusionList.length != 0 && !matchesList(request, inclusionList)) {
        return false;
    }

    if (bypassList.length != 0 && matchesList(request, bypassList)) {
        return false;
    }

    return true;
}

[ameshkov]

@erosman you have vast experience with proxy API, could you please provide some feedback on both APIs and on this idea?

[erosman]

proxy.onRequest

proxy.onRequest is a Firefox specific API and although it relates to proxying, it should be regarded as a separate area from proxy.settings.

Firefox proxy API does not allow configuring a PAC file

Firefox supports PAC file/script via proxy.settings, same as Chrome.

proxy.settings

There are a number of inconsistencies between chrome proxy.settings & Firefox proxy.settings and I have already filed a number of issues here and on Bugzilla accordingly.

1. Proxy Bypass list

Inconsistency: Proxy Bypass list

• In Firefox passthrough applies to individual proxy settings as well as autoConfigUrl
• In Chrome bypassList applies to individual proxy settings but NOT pacScript

2. Incognito

Inconsistency: incognito in proxy.settings

• Firefox proxy.settings requires incognito permission
• Chrome proxy.settings does not have the same requirement (but fails to set proxy in incognito without the permission)

3. QUIC (HTTP/3) scheme in proxy

• At the moment, QUIC (HTTP/3) proxy scheme is not supported in Firefox
• Chrome already supports QUIC proxy scheme i.e. "http", "https", "quic", "socks4", "socks5"

4. proxy.settings API Comparison

There are considerable differences between the properties and value formats of proxy.settings between Chrome & Firefox.

Chrome	Firefox
ProxyRules
singleProxy object scheme: http/https/socks4/socks5/quic	httpProxyAll boolean
proxyForHttp object	http string
proxyForHttps object	ssl string
proxyForFtp object	ftp string
fallbackProxy object
bypassList array	passthrough string
PacScript
url string	autoConfigUrl string
data string	autoConfigUrl string
Other
	autoLogin boolean
	socks string
	socksVersion integer
	proxyDNS boolean

[erosman]

re: inclusionList

inclusionList would be a new feature request and would better be discussed independently.

[ameshkov]

@erosman thank you for the very detailed list of differences!

Regarding the inclusion list, it is indeed a new feature request, I just don't understand where to file it.
If there's a common agreement on proxy.settings then it probably should be requested here.
If every browser continues to provide their own implementation, then I guess I should request it in Chrome's bug tracker.

Anyways, it is indeed off-topic here, I'll move it later to a more correct place.

[oliverdunk]

Removing the Chrome needs-triage label. We are generally supportive of aligning here where it makes sense, but based on discussion at the in-person meeting, it seems the most actionable work is for Firefox to investigate supporting the declarative style API. inclusionList sounds interesting but would need a separate API proposal.