Repository navigation
Drop Bing header rewrites from DNR and webRequest - #1112
PeterDaveHello wants to merge 1 commit into
Conversation
The legacy Bing Web provider used both mechanisms to rewrite Origin and Referer headers for www.bing.com and sydney.bing.com. Dropping only the DNR rule would leave Firefox's blocking webRequest listener rewriting those headers. Retire both paths together for consistent behavior across browsers.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (2)
💤 Files with no reviewable changes (2)
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe Bing-specific Origin and Referer rewrites were removed from the background listener and declarative rules. The separate Claude header listener and the ChatGPT and Claude header rules remain. ChangesBing request header rewrites
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~5 minutes Change: Other Merge Risk: ⚪ Minimal · up to No actionable breakage is established, so the change is mergeable after normal checks. Manual browser testing remains pending. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
PR Summary by QodoRemove Bing header rewrites across Chromium and Firefox
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
Code Review by Qodo
1.
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
There was a problem hiding this comment.
🟡 Changes recommended
The still-selectable Bing Web provider depends on the removed rewrites and will break before its planned removal.
1 open finding
What changed in this PR
Removes legacy Bing request-header rewriting across Chromium and Firefox.
Changes:
- Removes Bing DNR header rule.
- Removes matching background
webRequestlistener.
| File | Description |
|---|---|
src/rules.json |
Removes Chromium Bing header rewrites. |
src/background/index.mjs |
Removes Firefox Bing header listener. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| @@ -1,26 +1,4 @@ | |||
| [ | |||
There was a problem hiding this comment.
Updated to correct my earlier conclusion.
The Sydney WebSocket still has a caller, and the client cannot replace the browser-level Origin rewrite through the WebSocket constructor. Removing that rewrite before removing the provider is a valid sequencing concern.
The anonymous GET checks returned 404 HTML with and without the legacy headers, but that result cannot distinguish an unavailable endpoint from missing authentication. It does not justify keeping the original merge order or requiring an authenticated before/after reproduction before changing it.
Issue #805 reports that the Bing integration stopped working after the Copilot/Bing website redesign. That provides context for retiring the provider, but does not establish that every authenticated request path is unusable.
The safer merge order is to remove the Bing Web provider first, then merge this header cleanup. The PRs can remain separate; #1112 should wait until the provider removal has landed.
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes — deletion-only cleanup that retires the legacy Bing request-header overrides from both browser paths.
src/rules.json— removes DNR ruleid: 1, the Bingorigin/refererrewrite forwww.bing.com/sydney.bing.com. Thechatgpt.com(id: 2) andclaude.ai(id: 3) rules are unchanged.src/background/index.mjs— removes the BingwebRequest.onBeforeSendHeaderslistener and its MV2blockingflag; the Claude listener that follows it is untouched.
The Bing Web provider itself is still wired up, so on first read removing its header rewriting looks like a possible regression — the client's own Referer header is a forbidden header that fetch silently drops, leaving the deleted interceptor as the only mechanism that ever set Origin/Referer. It checks out as safe here because the endpoints that provider calls are retired (https://www.bing.com/turing/conversation/create?... returns 404, and Bing Chat was folded into Copilot), so the provider is already non-functional regardless of these headers. Repo-wide grep confirms this pair was the only place rewriting Bing Origin/Referer, and no test, doc, or rule-id reference depends on the removed rule.
deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 2 files
Confidence score: 3/5
- Removing the header rewrites in
src/rules.jsonmay break Bing Web for users who selectbingFree4orbingFreeSydney, since those providers remain active. Keep the rewrites or update the provider configuration.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/rules.json">
<violation number="1" location="src/rules.json:20">
P2: This removes the header rewrites for `sydney.bing.com`/`www.bing.com` while the Bing Web provider they supported is still active and user-selectable. `bingFree4`/`bingFreeSydney` remain selectable in `src/config/index.mjs` and still dispatch through `generateAnswersWithBingWebApi` at `src/background/index.mjs:559-567`. The Bing client's own `Referer` in its fetch init (`src/services/clients/bing/index.mjs:127`) is a forbidden request header and is silently dropped by browser `fetch()`, so the DNR rule (MV3) and the blocking listener (MV2) were the only mechanism putting the Bing origin/referer on the `/turing/conversation/create` XHR and the `wss://sydney.bing.com/sydney/ChatHub` handshake. With both removed, those requests now go out with `Origin: chrome-extension://<id>` and no Bing referer, which risks 403/rejection for the still-active Bing Web provider. The identical rewrite pattern is retained for chatgpt.com and claude.ai (rules 2/3 and the Claude listener), confirming it is still needed and only Bing's was dropped. Consider landing the Bing provider removal in the same PR, or keeping the rewrites until the follow-up lands, or explicitly documenting the interim breakage in the PR description.</violation>
</file>
Click Fix with cubic on a comment, or reply @cubic-dev-ai fix this, and cubic writes the fix.
View guided diff | Re-trigger cubic
| ] | ||
| }, | ||
| "condition": { | ||
| "requestDomains": ["sydney.bing.com", "www.bing.com"], |
There was a problem hiding this comment.
P2: This removes the header rewrites for sydney.bing.com/www.bing.com while the Bing Web provider they supported is still active and user-selectable. bingFree4/bingFreeSydney remain selectable in src/config/index.mjs and still dispatch through generateAnswersWithBingWebApi at src/background/index.mjs:559-567. The Bing client's own Referer in its fetch init (src/services/clients/bing/index.mjs:127) is a forbidden request header and is silently dropped by browser fetch(), so the DNR rule (MV3) and the blocking listener (MV2) were the only mechanism putting the Bing origin/referer on the /turing/conversation/create XHR and the wss://sydney.bing.com/sydney/ChatHub handshake. With both removed, those requests now go out with Origin: chrome-extension://<id> and no Bing referer, which risks 403/rejection for the still-active Bing Web provider. The identical rewrite pattern is retained for chatgpt.com and claude.ai (rules 2/3 and the Claude listener), confirming it is still needed and only Bing's was dropped. Consider landing the Bing provider removal in the same PR, or keeping the rewrites until the follow-up lands, or explicitly documenting the interim breakage in the PR description.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At src/rules.json, line 20:
<comment>This removes the header rewrites for `sydney.bing.com`/`www.bing.com` while the Bing Web provider they supported is still active and user-selectable. `bingFree4`/`bingFreeSydney` remain selectable in `src/config/index.mjs` and still dispatch through `generateAnswersWithBingWebApi` at `src/background/index.mjs:559-567`. The Bing client's own `Referer` in its fetch init (`src/services/clients/bing/index.mjs:127`) is a forbidden request header and is silently dropped by browser `fetch()`, so the DNR rule (MV3) and the blocking listener (MV2) were the only mechanism putting the Bing origin/referer on the `/turing/conversation/create` XHR and the `wss://sydney.bing.com/sydney/ChatHub` handshake. With both removed, those requests now go out with `Origin: chrome-extension://<id>` and no Bing referer, which risks 403/rejection for the still-active Bing Web provider. The identical rewrite pattern is retained for chatgpt.com and claude.ai (rules 2/3 and the Claude listener), confirming it is still needed and only Bing's was dropped. Consider landing the Bing provider removal in the same PR, or keeping the rewrites until the follow-up lands, or explicitly documenting the interim breakage in the PR description.</comment>
<file context>
@@ -1,26 +1,4 @@
[
- {
- "id": 1,
- "action": {
- "type": "modifyHeaders",
- "requestHeaders": [
- {
- "operation": "set",
- "header": "origin",
</file context>
There was a problem hiding this comment.
Updated to correct my earlier conclusion.
The selectable Bing models and dispatch path still use this client. Its fetch-init Referer does not replace the browser-level rewrites, so removing those rewrites before the provider is a valid sequencing concern.
The anonymous GET checks returned 404 HTML with and without the legacy headers, but that result cannot distinguish an unavailable endpoint from missing authentication. It does not justify keeping the original merge order or requiring an authenticated before/after reproduction before changing it.
Issue #805 reports that the Bing integration stopped working after the Copilot/Bing website redesign. That provides context for retiring the provider, but does not establish that every authenticated request path is unusable.
The safer merge order is to remove the Bing Web provider first, then merge this header cleanup. The PRs can remain separate; #1112 should wait until the provider removal has landed.
|
@coderabbitai what do you think? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
gh pr diff 1112 --repo ChatGPTBox-dev/chatGPTBox
ast-grep outline src/background/index.mjs --items all
rg -n -C4 'onBeforeSendHeaders|sydney\.bing\.com|www\.bing\.com|rule_resources|declarativeNetRequest|removeRuleIds|addRules' src -g '!**/locales/**'
cat -n src/rules.json
gh pr view 1112 --repo ChatGPTBox-dev/chatGPTBox --json title,body,statusCheckRollupLength of output: 28029
The remaining risk is the legacy Bing provider. It still connects to Before merging, I recommend a Chromium and Firefox smoke test. Confirm that Bing search-page extraction still works and that the extension no longer applies the Bing header rewrites. I have not verified browser behavior. You are interacting with an AI system. |
Retire the request-header overrides used by the legacy Bing Web provider for
www.bing.comandsydney.bing.com.This removes DNR rule 1 from
src/rules.jsonand the matchingwebRequest.onBeforeSendHeaderslistener fromsrc/background/index.mjs. Chromium MV3 relied on the DNR rule, while Firefox MV2 also applied the blocking listener. Removing both keeps the header behavior consistent across browsers.This PR isolates the header rewrite cleanup from the provider removal planned in a follow-up PR. Bing search-page extraction retains its host permissions, site adapter, and search result selector.
Validation
npm run pretty:checknpm run lintnpm testnpm run buildSummary by CodeRabbit
OriginandRefererheaders with Bing URLs. These requests retain their original header values instead. Header-handling behavior for ChatGPT and Claude remains unchanged, so this update affects only the handling of Bing requests and does not alter those other services.