Skip to content

fix(web): drop the dropped body's framing headers from an oversize error relay - #2774

Merged
cliffhall merged 1 commit into
v2/mainfrom
v2/fix/2771-oversize-error-framing-headers
Oct 21, 2026
Merged

cliffhall merged 1 commit into
v2/mainfrom
v2/fix/2771-oversize-error-framing-headers

Conversation

@cliffhall

Copy link
Copy Markdown
Member

Closes #2771

Problem

When /api/fetch refuses an oversized upstream body for an error status, it relays the status and headers with no body, so OAuth discovery can still act on a 404. The relayed headers were the upstream's verbatim, though, including the ones that described the dropped body. createRemoteFetch rebuilds a null-body Response from them, which then reported content-length: 5242880 (or transfer-encoding: chunked) for an empty body.

Change

  • core/mcp/remote/node/server.ts: on the oversize-error path only, the relayed headers omit content-length, transfer-encoding and content-encoding (withoutBodyFraming). Every other header is relayed as before. The success path (502) and normally relayed bodies are unchanged. Whether a normally relayed body should drop content-encoding/content-length after undici decodes it is a separate question, and this PR leaves it alone.

Tests

server-extra-coverage.test.ts, the two existing oversize-error cases:

  • Chunked: transfer-encoding is now absent, while content-type and x-probe are still relayed.
  • Declared length: content-length is now absent, while content-type is still relayed.

The file passes 83/83. Mutation check: relaying resHeaders unfiltered again fails exactly those two (2 failed | 81 passed).

npm run local:gate: green (exit 0). An earlier run went red only on smoke:web:browser [firefox] (page.goto timeout) while the network was degraded. A paired run in the same worktree then passed with the change stashed and with it applied, and the full re-run was green.

No UI change, so no screenshots.

🤖 Generated with Claude Code

…ror relay

When /api/fetch refuses an oversized body for an error status, it relays
the status and headers with no body. The relayed headers still carried
content-length / transfer-encoding / content-encoding for the dropped
body, so the browser rebuilt a null-body Response claiming a 5 MiB
length. Those three are now omitted on that path only.

Closes #2771

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Signed-off-by: cliffhall <cliff@futurescale.com>
@cliffhall cliffhall added the v2 Issues and PRs for v2 label Oct 21, 2026
@cliffhall
cliffhall requested a balanced review from Copilot October 21, 2026 16:29

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The narrow change matches the issue requirements, preserves other response paths, and has no unresolved findings.

No open issues 🎉

What changed in this PR

Fixes oversized upstream error responses relayed through /api/fetch so their headers no longer describe a discarded body.

Changes:

  • Removes content-length, transfer-encoding, and content-encoding only from oversized error responses.
  • Extends regression assertions to verify framing-header removal and preservation of other headers.
File Description
core/​mcp/​remote/​node/​server.ts Filters dropped-body headers on the oversized-error path.
clients/​web/​src/​test/​integration/​mcp/​remote/​server-extra-coverage.test.ts Checks chunked and declared-length error responses.

Review effort: Balanced

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v2 Issues and PRs for v2

Projects

None yet

Development

Successfully merging this pull request may close these issues.

/api/fetch relays the dropped body's framing headers when it refuses an oversized error response

2 participants