293576 2025-05-26 02:40:03 -0700 declarativeNetRequest modifyHeaders doesn't support custom headers 2025-06-13 12:02:51 -0700 1 1 1 Unclassified WebKit WebKit Extensions Safari 18 Mac (Apple Silicon) macOS 15 RESOLVED DUPLICATE 290922 InRadar P2 Major --- 1 vlkv webkit-unassigned timothy webkit-bug-importer oldest_to_newest 2119676 0 vlkv 2025-05-26 02:40:03 -0700 tl;dr: Safari ignores rules for `modifyHeaders` when making `fetch` request from MV3 extension. However, headers are successfully modified when making `chrome.runtime.sendMessage` request. I can reproduce this bug in Safari 18.5 and Safari Technology Preview Release 219. This bug can't be reproduced in the latest Chrome or Firefox. I have following `manifest.json` (MV3 extension): ``` "permissions": ["storage", "declarativeNetRequestWithHostAccess"], "host_permissions": ["http://localhost/*"], "declarative_net_request": { "rule_resources": [ { "id": "modify-origin", "enabled": true, "path": "rules.json" } ] }, ``` `rules.json`: ``` [ { "id": 1, "priority": 1, "action": { "type": "modifyHeaders", "requestHeaders": [ { "header": "Origin", "operation": "set", "value": "http://localhost" } ] }, "condition": { "urlFilter": "http://localhost:11434/*", "resourceTypes": ["xmlhttprequest"] } } ] ``` and `test-script.js`: ``` ... const response = await fetch('http://localhost:11434/api/generate', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: params }); console.log(response) const response2 = await new Promise((resolve, reject) => { chrome.runtime.sendMessage({ type: "ollama-fetch", url: "http://localhost:11434/api/generate", body: params }, (response) => { if (response && response.success) { resolve(response.data); } else { reject(response ? response.error : "No response"); } }); }); console.log(response2) ... ``` `fetch` request will end up ignoring `modifyHeaders` rule, but it works in other browsers. 2120034 1 webkit-bug-importer 2025-05-27 19:25:35 -0700 <rdar://problem/152126602> 2123547 2 timothy 2025-06-13 12:02:51 -0700 *** This bug has been marked as a duplicate of bug 290922 ***