[thepigdestroyer]

Summary

When the upstream provider returns a gzip-encoded response, the SSE bridge currently forwards content-encoding: gzip (and stale content-length / transfer-encoding) verbatim to the downstream OpenAI/Anthropic-compatible client. But fetch() has already transparently decompressed the body before we read it via .text() or the stream reader, so the client receives plain text labelled as gzip and explodes with ZlibError: incorrect header check.

This PR adds a small helper module and uses it at the two response-construction sites in open-sse/handlers/chatCore.ts (non-stream + stream).

Observed symptom that motivated this: real-world clients (e.g. the Anthropic SDK and some OpenAI proxies) fail with ZlibError mid-stream when the upstream happened to negotiate gzip. The fix is independent of which upstream provider was contacted — it's purely a "don't lie about how the body is encoded after we touched it" hygiene fix.

Changes

• New open-sse/utils/upstreamResponseHeaders.ts exporting:
  • stripStaleEncodingHeaders(input: Headers): Headers — case-insensitive, non-mutating; drops content-encoding, content-length, transfer-encoding.
  • filterUpstreamResponseHeaderEntries(entries, extraToStrip) — same semantics for the entries-array path used by the streaming response builder, plus user-supplied extra names (case-insensitive).
  • STRIP_UPSTREAM_HEADER_NAMES — the canonical set, exported for tests.
• open-sse/handlers/chatCore.ts — two call sites refactored:
  • Non-stream path (≈ L3211): new Headers(rawResult.response.headers) → stripStaleEncodingHeaders(rawResult.response.headers) (so the repacked new Response(...) below doesn't claim a stale encoding/length).
  • Stream path (≈ L4371): the inline IIFE + .filter() that only stripped content-type is replaced with filterUpstreamResponseHeaderEntries(providerResponse.headers.entries(), ["content-type"]) so the stale encoding/length get stripped too before we set our own Content-Type: text/event-stream.
• Both sites carry an explanatory comment about the underlying fetch() decompression behavior.

Related Issues

• Closes #
• Related to #

Validation

• npm run lint (scoped: npx eslint on the three touched files — clean)
• npm run test:unit — 122 test files, exceeds local timeout window; deferring to upstream CI
• npm run test:coverage — same; deferring to upstream CI
• npm run typecheck:core — clean
• Targeted unit run — node --import tsx/esm --test tests/unit/upstream-response-headers-strip.test.ts tests/unit/upstream-headers-sanitize.test.ts tests/unit/chatcore-sanitization.test.ts tests/unit/chat-route-edge-cases.test.ts tests/unit/chatcore-translation-paths.test.ts tests/unit/chatcore-compression-integration.test.ts — 95/95 pass
• Coverage is still >= 60% for statements, lines, functions, and branches — full coverage run deferred to upstream CI; the change is small (one new module + 2 call sites) and the new test exercises every public export.
• SonarQube PR analysis — will defer to upstream CI run.

Tests Added Or Updated

• Added tests/unit/upstream-response-headers-strip.test.ts (10 cases):
  • stripStaleEncodingHeaders — removes lowercase / removes mixed-case / does not mutate input / handles empty input.
  • filterUpstreamResponseHeaderEntries — strips default set / case-insensitive extraToStrip / empty extraToStrip preserves headers / empty input returns empty array / mixed-case default names.
  • STRIP_UPSTREAM_HEADER_NAMES — canonical set identity.

No existing test was modified.

Coverage Notes

• This PR touches open-sse/ (the new util module + 2 call sites in chatCore.ts).
• The new helper module is fully covered by the new test (every exported symbol, every parameter mode).
• The two new call sites in chatCore.ts exchange one stale-headers expression for one strip-headers expression — coverage of the surrounding non-stream / stream branches is unchanged (still exercised by tests/unit/chat-route-edge-cases.test.ts, tests/unit/chatcore-translation-paths.test.ts, tests/unit/chatcore-compression-integration.test.ts, all passing locally).
• Total touched-file coverage should net-up, not down.

Reviewer Notes

• This is a defensive header-hygiene fix; no behavioral change for clients that didn't negotiate gzip upstream.
• The helper module is intentionally tiny and side-effect-free so it's safe to import from anywhere else in open-sse/.
• The case-insensitivity matters because real provider responses mix Content-Encoding (Anthropic) and content-encoding (some OpenAI compatibles) in practice — the new test pins both.
• I left an explanatory code comment at both call sites so future contributors don't accidentally reintroduce the leak.
• Local CI hooks ran (lint-staged, check-docs-sync, check:any-budget:t11, check-env-doc-sync, i18n drift/coverage warn-only) and were green at commit time.

[gemini-code-assist]

Code Review

This pull request introduces a utility to strip stale encoding and length headers from upstream provider responses to prevent client-side decompression errors. It adds a new utility file open-sse/utils/upstreamResponseHeaders.ts containing stripStaleEncodingHeaders and filterUpstreamResponseHeaderEntries, integrates these into open-sse/handlers/chatCore.ts, and adds corresponding unit tests. I have no feedback to provide.