Reference: Bug 1545420 & [D29825](https://phabricator.services.mozilla.com/D29825) Originally, `proxy.onRequest` was created to process proxy forwarding and authenticating. - The API can handle HTTP/HTTPS/SOCKS4/SOCKS5 proxy forwarding - The API can also provide authentication for SOCKS5 (unique to Firefox), as well as HTTPS proxies AT the moment, proxying using `proxy.onRequest` involves: - Forwarding to SOCKS4 proxies (*no authentication as it is not supported*) - Forwarding & authenticating withing the same process to SOCKS5 proxies - Forwarding & authenticating withing the same process to HTTPS proxies as basic authentication header e.g. `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` - Forwarding to HTTP proxies As a result, in case of HTTP proxies, forwarding and authenticating can not be performed within the same process and additional lighteners (and permissions) are needed. > [webRequest.onAuthRequired](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired) > > **Proxy authorization** > If an extension has the "webRequest", "webRequestBlocking", "proxy", and "<all_urls>" permissions, then it will be able to use onAuthRequired to supply credentials for proxy authorization (but not for normal web authorization). ```js browser.webRequest.onAuthRequired.addListener() browser.webRequest.onCompleted.addListener() browser.webRequest.onErrorOccurred.addListener() ``` Performance Comparison: - Forwarding to proxy with `Proxy-Authorization` headers in one process (as is the case with SOCKS5 & HTTPS) ----- vs ----- - Forwarding to the proxy (HTTP) - Adding a listeners to wait for HTTP 407 - Replying to the HTTP 407 after retrieving user/pass If HTTP authentication header was also permitted in `proxy.onRequest`, then there would not be any need to resort to a separate API (actually 3 APIs) simply to handle sending authentication for HTTP proxies. In fact, the other APIs eventually end up sending the authentication as `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` header anyway. Currently, `proxy.onRequest` disables setting `proxyAuthorizationHeader` for HTTP in https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ProxyChannelFilter.jsm#173 ```js proxyAuthorizationHeader(proxyData) { let { proxyAuthorizationHeader, type } = proxyData; if (proxyAuthorizationHeader === undefined) { return; } if (typeof proxyAuthorizationHeader !== "string") { throw new ExtensionError( `ProxyInfoData: Invalid proxy server authorization header: "${proxyAuthorizationHeader}"` ); } if (type !== "https") { throw new ExtensionError( `ProxyInfoData: ProxyAuthorizationHeader requires type "https"` ); } }, ``` Above limit was requested in [D29825](https://phabricator.services.mozilla.com/D29825). If there are no underlying issues, then the removal of lines 183-187 should enhance the `proxy.onRequest` and improve the overall performance by processing everything within the same process.
Bug 1794464 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Reference: Bug 1545420 & [D29825](https://phabricator.services.mozilla.com/D29825) Originally, `proxy.onRequest` was created to process proxy forwarding and authenticating. - The API can handle HTTP/HTTPS/SOCKS4/SOCKS5 proxy forwarding - The API can also provide authentication for SOCKS5 (unique to Firefox), as well as HTTPS proxies At the moment, proxying using `proxy.onRequest` involves: - Forwarding to SOCKS4 proxies (*no authentication as it is not supported*) - Forwarding & authenticating withing the same process to SOCKS5 proxies - Forwarding & authenticating withing the same process to HTTPS proxies as basic authentication header e.g. `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` - Forwarding to HTTP proxies As a result, in case of HTTP proxies, forwarding and authenticating can not be performed within the same process and additional lighteners (and permissions) are needed. > [webRequest.onAuthRequired](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired) > > **Proxy authorization** > If an extension has the "webRequest", "webRequestBlocking", "proxy", and "<all_urls>" permissions, then it will be able to use onAuthRequired to supply credentials for proxy authorization (but not for normal web authorization). ```js browser.webRequest.onAuthRequired.addListener() browser.webRequest.onCompleted.addListener() browser.webRequest.onErrorOccurred.addListener() ``` Performance Comparison: - Forwarding to proxy with `Proxy-Authorization` headers in one process (as is the case with SOCKS5 & HTTPS) ----- vs ----- - Forwarding to the proxy (HTTP) - Adding a listeners to wait for HTTP 407 - Replying to the HTTP 407 after retrieving user/pass If HTTP authentication header was also permitted in `proxy.onRequest`, then there would not be any need to resort to a separate API (actually 3 APIs) simply to handle sending authentication for HTTP proxies. In fact, the other APIs eventually end up sending the authentication as `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` header anyway. Currently, `proxy.onRequest` disables setting `proxyAuthorizationHeader` for HTTP in https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ProxyChannelFilter.jsm#173 ```js proxyAuthorizationHeader(proxyData) { let { proxyAuthorizationHeader, type } = proxyData; if (proxyAuthorizationHeader === undefined) { return; } if (typeof proxyAuthorizationHeader !== "string") { throw new ExtensionError( `ProxyInfoData: Invalid proxy server authorization header: "${proxyAuthorizationHeader}"` ); } if (type !== "https") { throw new ExtensionError( `ProxyInfoData: ProxyAuthorizationHeader requires type "https"` ); } }, ``` Above limit was requested in [D29825](https://phabricator.services.mozilla.com/D29825). If there are no underlying issues, then the removal of lines 183-187 should enhance the `proxy.onRequest` and improve the overall performance by processing everything within the same process.
Reference: Bug 1545420 & [D29825](https://phabricator.services.mozilla.com/D29825) Originally, `proxy.onRequest` was created to process proxy forwarding and authenticating. - The API can handle HTTP/HTTPS/SOCKS4/SOCKS5 proxy forwarding - The API can also provide authentication for SOCKS5 (unique to Firefox), as well as HTTPS proxies At the moment, proxying using `proxy.onRequest` involves: - Forwarding to SOCKS4 proxies (*no authentication as it is not supported*) - Forwarding & authenticating withing the same process to SOCKS5 proxies - Forwarding & authenticating withing the same process to HTTPS proxies as basic authentication header e.g. `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` - Forwarding to HTTP proxies As a result, in case of HTTP proxies, forwarding and authenticating can not be performed within the same process and additional listeners (and permissions) are needed. > [webRequest.onAuthRequired](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired) > > **Proxy authorization** > If an extension has the "webRequest", "webRequestBlocking", "proxy", and "<all_urls>" permissions, then it will be able to use onAuthRequired to supply credentials for proxy authorization (but not for normal web authorization). ```js browser.webRequest.onAuthRequired.addListener() browser.webRequest.onCompleted.addListener() browser.webRequest.onErrorOccurred.addListener() ``` Performance Comparison: - Forwarding to proxy with `Proxy-Authorization` headers in one process (as is the case with SOCKS5 & HTTPS) ----- vs ----- - Forwarding to the proxy (HTTP) - Adding a listeners to wait for HTTP 407 - Replying to the HTTP 407 after retrieving user/pass If HTTP authentication header was also permitted in `proxy.onRequest`, then there would not be any need to resort to a separate API (actually 3 APIs) simply to handle sending authentication for HTTP proxies. In fact, the other APIs eventually end up sending the authentication as `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` header anyway. Currently, `proxy.onRequest` disables setting `proxyAuthorizationHeader` for HTTP in https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ProxyChannelFilter.jsm#173 ```js proxyAuthorizationHeader(proxyData) { let { proxyAuthorizationHeader, type } = proxyData; if (proxyAuthorizationHeader === undefined) { return; } if (typeof proxyAuthorizationHeader !== "string") { throw new ExtensionError( `ProxyInfoData: Invalid proxy server authorization header: "${proxyAuthorizationHeader}"` ); } if (type !== "https") { throw new ExtensionError( `ProxyInfoData: ProxyAuthorizationHeader requires type "https"` ); } }, ``` Above limit was requested in [D29825](https://phabricator.services.mozilla.com/D29825). If there are no underlying issues, then the removal of lines 183-187 should enhance the `proxy.onRequest` and improve the overall performance by processing everything within the same process.
### Preamble This bug was filed subsequent to a discussion with Valentine in https://chat.mozilla.org/#/room/#necko:mozilla.org and a request to file a bug in https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Networking API was restricted due to the request in [D29825](https://phabricator.services.mozilla.com/D29825): > can you restrict this only for https proxies? > Why exactly should this be limited to https proxies only? > Because we limit any new stuff to https only. ### Background Reference: Bug 1545420 & [D29825](https://phabricator.services.mozilla.com/D29825) Originally, `proxy.onRequest` was created to process proxy forwarding and authenticating. - The API can handle HTTP/HTTPS/SOCKS4/SOCKS5 proxy forwarding - The API can also provide authentication for SOCKS5 (unique to Firefox), as well as HTTPS proxies At the moment, proxying using `proxy.onRequest` involves: - Forwarding to SOCKS4 proxies (*no authentication as it is not supported*) - Forwarding & authenticating withing the same process to SOCKS5 proxies - Forwarding & authenticating withing the same process to HTTPS proxies as basic authentication header e.g. `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` - Forwarding to HTTP proxies As a result, in case of HTTP proxies, forwarding and authenticating can not be performed within the same process and additional listeners (and permissions) are needed. > [webRequest.onAuthRequired](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired) > > **Proxy authorization** > If an extension has the "webRequest", "webRequestBlocking", "proxy", and "<all_urls>" permissions, then it will be able to use onAuthRequired to supply credentials for proxy authorization (but not for normal web authorization). ```js browser.webRequest.onAuthRequired.addListener() browser.webRequest.onCompleted.addListener() browser.webRequest.onErrorOccurred.addListener() ``` Performance Comparison: - Forwarding to proxy with `Proxy-Authorization` headers in one process (as is the case with SOCKS5 & HTTPS) ----- vs ----- - Forwarding to the proxy (HTTP) - Adding a listeners to wait for HTTP 407 - Replying to the HTTP 407 after retrieving user/pass If HTTP authentication header was also permitted in `proxy.onRequest`, then there would not be any need to resort to a separate API (actually 3 APIs) simply to handle sending authentication for HTTP proxies. In fact, the other APIs eventually end up sending the authentication as `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` header anyway. Currently, `proxy.onRequest` disables setting `proxyAuthorizationHeader` for HTTP in https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ProxyChannelFilter.jsm#173 ```js proxyAuthorizationHeader(proxyData) { let { proxyAuthorizationHeader, type } = proxyData; if (proxyAuthorizationHeader === undefined) { return; } if (typeof proxyAuthorizationHeader !== "string") { throw new ExtensionError( `ProxyInfoData: Invalid proxy server authorization header: "${proxyAuthorizationHeader}"` ); } if (type !== "https") { throw new ExtensionError( `ProxyInfoData: ProxyAuthorizationHeader requires type "https"` ); } }, ``` ### Request Above limit was requested in [D29825](https://phabricator.services.mozilla.com/D29825). If there are no underlying issues, then the removal of lines 183-187 should enhance the `proxy.onRequest` and improve the overall performance by processing everything within the same process.
### Preamble The bug was filed subsequent to a discussion with Valentine in [#necko:mozilla.org](https://chat.mozilla.org/#/room/#necko:mozilla.org) and instruction to file a bug under https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Networking API was restricted due to the request in [D29825](https://phabricator.services.mozilla.com/D29825): > can you restrict this only for https proxies? > Why exactly should this be limited to https proxies only? > Because we limit any new stuff to https only. ### Background Reference: Bug 1545420 & [D29825](https://phabricator.services.mozilla.com/D29825) Originally, `proxy.onRequest` was created to process proxy forwarding and authenticating. - The API can handle HTTP/HTTPS/SOCKS4/SOCKS5 proxy forwarding - The API can also provide authentication for SOCKS5 (unique to Firefox), as well as HTTPS proxies At the moment, proxying using `proxy.onRequest` involves: - Forwarding to SOCKS4 proxies (*no authentication as it is not supported*) - Forwarding & authenticating withing the same process to SOCKS5 proxies - Forwarding & authenticating withing the same process to HTTPS proxies as basic authentication header e.g. `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` - Forwarding to HTTP proxies As a result, in case of HTTP proxies, forwarding and authenticating can not be performed within the same process and additional listeners (and permissions) are needed. > [webRequest.onAuthRequired](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired) > > **Proxy authorization** > If an extension has the "webRequest", "webRequestBlocking", "proxy", and "<all_urls>" permissions, then it will be able to use onAuthRequired to supply credentials for proxy authorization (but not for normal web authorization). ```js browser.webRequest.onAuthRequired.addListener() browser.webRequest.onCompleted.addListener() browser.webRequest.onErrorOccurred.addListener() ``` Performance Comparison: - Forwarding to proxy with `Proxy-Authorization` headers in one process (as is the case with SOCKS5 & HTTPS) ----- vs ----- - Forwarding to the proxy (HTTP) - Adding a listeners to wait for HTTP 407 - Replying to the HTTP 407 after retrieving user/pass If HTTP authentication header was also permitted in `proxy.onRequest`, then there would not be any need to resort to a separate API (actually 3 APIs) simply to handle sending authentication for HTTP proxies. In fact, the other APIs eventually end up sending the authentication as `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` header anyway. Currently, `proxy.onRequest` disables setting `proxyAuthorizationHeader` for HTTP in https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ProxyChannelFilter.jsm#173 ```js proxyAuthorizationHeader(proxyData) { let { proxyAuthorizationHeader, type } = proxyData; if (proxyAuthorizationHeader === undefined) { return; } if (typeof proxyAuthorizationHeader !== "string") { throw new ExtensionError( `ProxyInfoData: Invalid proxy server authorization header: "${proxyAuthorizationHeader}"` ); } if (type !== "https") { throw new ExtensionError( `ProxyInfoData: ProxyAuthorizationHeader requires type "https"` ); } }, ``` ### Request Above limit was requested in [D29825](https://phabricator.services.mozilla.com/D29825). If there are no underlying issues, then the removal of lines 183-187 should enhance the `proxy.onRequest` and improve the overall performance by processing everything within the same process.
### Preamble The bug was filed subsequent to a discussion with Valentin in [#necko:mozilla.org](https://chat.mozilla.org/#/room/#necko:mozilla.org) and instruction to file a bug under https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Networking API was restricted due to the request in [D29825](https://phabricator.services.mozilla.com/D29825): > can you restrict this only for https proxies? > Why exactly should this be limited to https proxies only? > Because we limit any new stuff to https only. ### Background Reference: Bug 1545420 & [D29825](https://phabricator.services.mozilla.com/D29825) Originally, `proxy.onRequest` was created to process proxy forwarding and authenticating. - The API can handle HTTP/HTTPS/SOCKS4/SOCKS5 proxy forwarding - The API can also provide authentication for SOCKS5 (unique to Firefox), as well as HTTPS proxies At the moment, proxying using `proxy.onRequest` involves: - Forwarding to SOCKS4 proxies (*no authentication as it is not supported*) - Forwarding & authenticating withing the same process to SOCKS5 proxies - Forwarding & authenticating withing the same process to HTTPS proxies as basic authentication header e.g. `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` - Forwarding to HTTP proxies As a result, in case of HTTP proxies, forwarding and authenticating can not be performed within the same process and additional listeners (and permissions) are needed. > [webRequest.onAuthRequired](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired) > > **Proxy authorization** > If an extension has the "webRequest", "webRequestBlocking", "proxy", and "<all_urls>" permissions, then it will be able to use onAuthRequired to supply credentials for proxy authorization (but not for normal web authorization). ```js browser.webRequest.onAuthRequired.addListener() browser.webRequest.onCompleted.addListener() browser.webRequest.onErrorOccurred.addListener() ``` Performance Comparison: - Forwarding to proxy with `Proxy-Authorization` headers in one process (as is the case with SOCKS5 & HTTPS) ----- vs ----- - Forwarding to the proxy (HTTP) - Adding a listeners to wait for HTTP 407 - Replying to the HTTP 407 after retrieving user/pass If HTTP authentication header was also permitted in `proxy.onRequest`, then there would not be any need to resort to a separate API (actually 3 APIs) simply to handle sending authentication for HTTP proxies. In fact, the other APIs eventually end up sending the authentication as `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` header anyway. Currently, `proxy.onRequest` disables setting `proxyAuthorizationHeader` for HTTP in https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ProxyChannelFilter.jsm#173 ```js proxyAuthorizationHeader(proxyData) { let { proxyAuthorizationHeader, type } = proxyData; if (proxyAuthorizationHeader === undefined) { return; } if (typeof proxyAuthorizationHeader !== "string") { throw new ExtensionError( `ProxyInfoData: Invalid proxy server authorization header: "${proxyAuthorizationHeader}"` ); } if (type !== "https") { throw new ExtensionError( `ProxyInfoData: ProxyAuthorizationHeader requires type "https"` ); } }, ``` ### Request Above limit was requested in [D29825](https://phabricator.services.mozilla.com/D29825). If there are no underlying issues, then the removal of lines 183-187 should enhance the `proxy.onRequest` and improve the overall performance by processing everything within the same process.
### Preamble The bug was filed subsequent to a discussion with Valentin in [#necko:mozilla.org](https://chat.mozilla.org/#/room/#necko:mozilla.org) and instruction to file a bug under https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Networking API was restricted due to the request in [D29825](https://phabricator.services.mozilla.com/D29825): > can you restrict this only for https proxies? > Why exactly should this be limited to https proxies only? > Because we limit any new stuff to https only. ### Background Reference: Bug 1545420 & [D29825](https://phabricator.services.mozilla.com/D29825) Originally, `proxy.onRequest` was created to process proxy forwarding and authenticating. - The API can handle HTTP/HTTPS/SOCKS4/SOCKS5 proxy forwarding - The API can also provide authentication for SOCKS5 (unique to Firefox), as well as HTTPS proxies At the moment, proxying using `proxy.onRequest` involves: - Forwarding to SOCKS4 proxies (*no authentication as it is not supported*) - Forwarding & authenticating withing the same process to SOCKS5 proxies - Forwarding & authenticating withing the same process to HTTPS proxies as basic authentication header e.g. `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` - Forwarding to HTTP proxies As a result, in case of HTTP proxies, forwarding and authenticating can not be performed within the same process and additional listeners (and permissions) are needed. > [webRequest.onAuthRequired](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired) > > **Proxy authorization** > If an extension has the "webRequest", "webRequestBlocking", "proxy", and "<all_urls>" permissions, then it will be able to use onAuthRequired to supply credentials for proxy authorization (but not for normal web authorization). ```js browser.webRequest.onAuthRequired.addListener() browser.webRequest.onCompleted.addListener() browser.webRequest.onErrorOccurred.addListener() ``` Performance Comparison: - Forwarding to proxy with `Proxy-Authorization` headers in one process (as is the case with SOCKS5 & HTTPS) ----- vs ----- - Forwarding to the proxy (HTTP) - Adding a listeners to wait for HTTP 407 - Replying to the HTTP 407 after retrieving user/pass If HTTP authentication header was also permitted in `proxy.onRequest`, then there would not be any need to resort to a separate API (actually 3 APIs) simply to handle sending authentication for HTTP proxies. In fact, the other APIs eventually end up sending the authentication as `Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` header anyway. Currently, `proxy.onRequest` disables setting `proxyAuthorizationHeader` for HTTP in ~https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ProxyChannelFilter.jsm#173~ https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ProxyChannelFilter.sys.mjs#167 *(updated URL 2024-01-23)* ```js proxyAuthorizationHeader(proxyData) { let { proxyAuthorizationHeader, type } = proxyData; if (proxyAuthorizationHeader === undefined) { return; } if (typeof proxyAuthorizationHeader !== "string") { throw new ExtensionError( `ProxyInfoData: Invalid proxy server authorization header: "${proxyAuthorizationHeader}"` ); } if (type !== "https") { throw new ExtensionError( `ProxyInfoData: ProxyAuthorizationHeader requires type "https"` ); } }, ``` ### Request Above limit was requested in [D29825](https://phabricator.services.mozilla.com/D29825). If there are no underlying issues, then the removal of lines 183-187 should enhance the `proxy.onRequest` and improve the overall performance by processing everything within the same process.