onBeforeSendHeaders not working in Chromium for certain "extra" headers

[p0358]

This isn't present in Firefox, but that polyfill doesn't cover it currently. Consider the following example:

function appendReferer(e) {
    e.requestHeaders.push({name: "Referer", value: "https://example.org"});
    return {requestHeaders: e.requestHeaders};
}

browser.webRequest.onBeforeSendHeaders.addListener(appendReferer,
    {urls: ["https://example.com"]},
    ["blocking", "requestHeaders"]
);

Now that will work in Firefox just fine. But apparently in Chromium since some time you need to add extraHeaders to extraInfoSpec in order to be able to retrieve and modify some headers.

So something like this would fix the above example then:

function appendReferer(e) {
    e.requestHeaders.push({name: "Referer", value: "https://example.org"});
    return {requestHeaders: e.requestHeaders};
}

let appendReferer_extraInfoSpec = ["blocking", "requestHeaders"];
if (chrome.webRequest.OnBeforeSendHeadersOptions.hasOwnProperty('EXTRA_HEADERS')) appendReferer_extraInfoSpec.push('extraHeaders');

browser.webRequest.onBeforeSendHeaders.addListener(appendReferer,
    {urls: ["https://example.com"]},
    appendReferer_extraInfoSpec
);

My simple fix proposition:
check the listener of onBeforeSendHeaders, if the resulting requestHeaders contain any of the "extra" headers, do push "extraHeaders" to extraInfoSpec before sending that to chrome

Affected headers include (https://developer.chrome.com/extensions/webRequest):

• Origin
• Accept-Language
• Accept-Encoding
• Referer
• Cookie
• Set-Cookie

[Rob--W]

In Chrome, there is a slight performance cost to using those headers, which is the reason for excluding those headers by default, with an opt in. While extensions could work by unconditionally adding the "extraHeaders" option to the list, this would defeat the reason for the existence of "extraHeaders".

For optimal performance and compatibility, you should only add extraHeaders if needed and supported.

[p0358]

@Rob--W I'm aware there is some reason they implemented this. The issue was that it's not supported by this polyfill and that leads to behavior change that's not so obvious to spot and fix for the developer. As far as I know this project is made to make transition from Firefox's API to Chrome's seamless. That is include this file and it works.

So the onBeforeSendHeaders polyfill should check the callback result, and if it has requestHeaders property that contains any of affected headers, it should automatically add extraHeaders to extraInfoSpec and then forward that to Chrome's API.

The issue should be reopened.

[Rob--W]

As far as I know this project is made to make transition from Firefox's API to Chrome's seamless.

That is not the case. This project was made to allow extension developers to use the Promise API. Not everything is supported: https://github.com/mozilla/webextension-polyfill#known-limitations-and-incompatibilities

So the onBeforeSendHeaders polyfill should check the callback result, and if it has requestHeaders property that contains any of affected headers, it should automatically add extraHeaders to extraInfoSpec and then forward that to Chrome's API.

This can't work.
The extraHeaders flag needs to be added upfront. It cannot be added while a request is being handled. The headers that you're interested in would be missing from the details.requestHeaders list without the extraHeaders flag.

The only way to get the ability to read or modify the header is to add the extraHeaders flag before the event is fired (when the event handler is registered). It is not possible to do it otherwise.

[p0358]

The headers that you're interested in would be missing from the details.requestHeaders list without the extraHeaders flag.

Actually I was only interested in adding/changing a particular header in my case, not in reading the existing ones.
But nonetheless, thinking it through, you're right, my idea couldn't work.
Nvm then