declarativeNetRequest modifyHeaders doesn't work for fetch requests initiated from the same Safari extension

ModifyHeaders in declarativeNetRequest  does not work for fetch requests from the extension.
This might be since the extension does not have permission over the safari-extension://GUID/ origin which is reset on every browser launch.

Expected behaviour:
The extension should have permissions for its own origin by default and should be able to modify headers for requests initiated from its own background page.

As such adding a rule like this should work:

browser.declarativeNetRequest.updateDynamicRules({
   addRules: [{
      "id": 1, 
      "priority": 1, 
      "action": {
         "type": "modifyHeaders", 
         "requestHeaders": [{"header": "origin", "operation": "set", "value": "https://www.bar.com"}]
      }, 
      "condition": {
         "urlFilter": "http://foo.com", // Any URL that the extension has permissions for
         "resourceTypes": ["main_frame", "xmlhttprequest"]
      }
   }],
})


Current behaviour:
The rule currently does not work

[Radar WebKit Bug Importer]

<rdar://problem/106851279>

Bump! 


Summary: Consider allowing header modification (specifically the origin) using declarativeNetRequest modifyHeaders for fetch requests made by the extension.

[Karl Dubost]

Thanks for the report, probably a duplicate of

*** This bug has been marked as a duplicate of bug 246493 ***

[Karl Dubost]

*** Bug 263818 has been marked as a duplicate of this bug. ***

[Karl Dubost]

I'm changing the resolution as declarativeNetRequest has been released but some of its features are not implemented.

[Nicholas Lim]

Hi, may I know if there is a tracker for progress on the declarativeNetRequest API? Thanks!

[Gabriel Aubut-Lussier]

I would like to add that websocket connections are also affected by this current limitation. Assuming the resourceTypes also include "websocket", I would expect a `new WebSocket("wss://example.com");` to match against the rule and be modified accordingly.