fix: preserve request headers on HTTP 3xx redirects

[Protocol-zero-0]

Problem

When a model provider base URL uses http and the server responds with a redirect (e.g. 307) to https, Chromium treats this as a cross-origin redirect and strips sensitive headers such as Authorization and custom headers. Users see failed provider checks / auth errors even though the endpoint works.

Closes #13236

Solution

• Add createFetchPreservingHeadersOnRedirect that follows redirects with redirect: 'manual' and reapplies the same method, body, and headers (RFC 303: switch to GET and drop content headers).
• Compose it with the existing developer→system role fetch wrapper in providerToAiSdkConfig so all modern SDK provider requests benefit.

Tests

• Unit tests for 307 (headers + POST body preserved) and 303 (GET, no body).

Made with Cursor

[Copilot]

Pull request overview

Fixes provider authentication failures caused by Chromium stripping sensitive/custom headers on cross-origin HTTP redirects (notably http → https) by introducing a manual-redirect-following fetch wrapper and applying it to modern AI SDK provider requests.

Changes:

• Added createFetchPreservingHeadersOnRedirect wrapper to manually follow 3xx redirects while reapplying method/body/headers (with special handling for 303).
• Composed the redirect-preserving fetch wrapper with the existing developer→system role conversion fetch wrapper in providerToAiSdkConfig.
• Added Vitest unit coverage for 307 (preserve headers + POST body) and 303 (switch to GET, drop body).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/renderer/src/aiCore/provider/providerConfig.ts	Wraps the provider fetch used by modern SDK configs with the new redirect-preserving fetch implementation.
src/renderer/src/aiCore/provider/preserveHeadersOnRedirectFetch.ts	Implements manual redirect following logic intended to preserve Authorization/custom headers across redirects.
src/renderer/src/aiCore/provider/__tests__/providerConfig.redirectFetch.test.ts	Adds unit tests validating redirect behavior for 307 and 303 scenarios.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Security: this redirect-follow implementation will re-send Authorization and any custom headers to whatever host appears in Location. That enables credential exfiltration via open redirects or MITM when the user config is http:// (the exact scenario in #13236). Please restrict header preservation to safe redirects (e.g., only allow http -> https upgrade with the same hostname+port, or same-origin), and for other redirects either drop sensitive headers (Authorization/X-Api-Key/etc.) or stop following and surface a clear error.

[Copilot]

For 301/302, the current logic preserves method+body across redirects. That diverges from standard fetch redirect behavior (many clients switch POST to GET for 301/302, while 307/308 are the ones that guarantee method preservation). To avoid surprising compatibility issues, consider either handling 301/302 like fetch (switch to GET and drop body/content headers similarly to 303 for non-GET/HEAD), or remove 301/302 from REDIRECT_STATUSES so you don’t change semantics for those cases.

Suggested change

	const REDIRECT_STATUSES = new Set([301, 302, 303, 307, 308])
	const REDIRECT_STATUSES = new Set([303, 307, 308])

[Copilot]

When switching to GET for a 303 you only delete Content-Type/Content-Length. Other Content-* headers (e.g., content-encoding) could also be left behind and produce invalid requests. Consider removing all headers whose name starts with content- when dropping the body, rather than hard-coding a small list.

Suggested change

	h.delete('content-type')
	h.delete('Content-Type')
	h.delete('content-length')
	h.delete('Content-Length')
	h.forEach((_, key) => {
	if (key.toLowerCase().startsWith('content-')) {
	h.delete(key)
	}
	})

[Protocol-zero-0]

Updated the redirect wrapper to address the security concerns. Sensitive headers are now only preserved for same-origin redirects or same-host http→https upgrades. For other redirects, the wrapper follows safely but strips sensitive auth-style headers. I also aligned 301/302 handling with standard fetch semantics for POST redirects and broadened content-header cleanup, with focused tests covering safe redirect preservation, cross-origin auth stripping, and 302/303 behavior.

[DeJeune]

LGTM. The security handling for cross-origin vs same-host redirects is solid, and the test coverage is good.

[Protocol-zero-0]

Synced this branch with latest upstream/main and resolved merge conflicts in provider config. The redirect header-preservation logic is still intact after the sync. Please take another look when convenient.

[Protocol-zero-0]

Quick follow-up: this branch is now synced with current main and conflict-free. Could a maintainer help with a re-review when available?

[Protocol-zero-0]

Synced this branch to latest main again today and resolved the new merge drift. No failing checks on the updated head. If maintainers are okay with current scope, this should be ready for final merge/review action.

[JackieJK]

error when my cherrystudio v2.0.3 fetch https://officecli.ai/SKILL.md
so when this PR could merged?

[0xfullex]

Thank you very much for your contribution and for your patience while the v2 work was landing.

We are now reviewing pull requests opened before the v2 transition. This PR has not received a recent code update and no longer applies cleanly to the latest main branch after the extensive v2 refactor. In its current state, the diff cannot be reviewed or merged safely without being rebased or reworked against the current architecture.

We are leaving the PR open for now. If you would like to continue the work, please rebase or recreate the change from the latest main branch and push a meaningful code update within 14 days of this comment. If there is no update during that time, the PR may be closed as stale. A fresh PR is also very welcome if that would provide a cleaner history.

Thank you again for the work and for your understanding.

[Protocol-zero-0]

Reworked this fix against the current v2 main-process networking architecture in #19614. The new PR moves safe redirect handling to the shared provider customFetch, retains the earlier security constraints, and includes updated regression coverage. Closing this superseded PR in favor of the clean v2 implementation.