fix(client): decompress gzip token response bodies in oauth flows#2436
Open
KlyneChrysler wants to merge 1 commit into
Open
fix(client): decompress gzip token response bodies in oauth flows#2436KlyneChrysler wants to merge 1 commit into
KlyneChrysler wants to merge 1 commit into
Conversation
Fixes modelcontextprotocol#2408. Fetch implementations only auto-decompress when the response carries a usable Content-Encoding header. A proxy that strips the header, or a custom fetchFn that surfaces raw bytes, hands the SDK gzip bytes that crash response.json() during token exchange. Token and OAuth error response bodies are now sniffed for the gzip magic bytes and decompressed via the web-standard DecompressionStream before JSON parsing, with a json()/text() fallback for minimal Response-like objects.
🦋 Changeset detectedLatest commit: 8840fa9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/core
@modelcontextprotocol/server
@modelcontextprotocol/server-legacy
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fixes #2408
why the maintainer repro failed
undici (and every spec-compliant fetch) auto-decompresses only when the response carries a usable
Content-Encodingheader, which is why a mock server returning proper gzip headers could not reproduce the crash. the failing environments get raw gzip bytes past fetch in two ways:Content-Encodingheader while leaving the body compressed, so fetch never decompressesfetchFnbuilt on something that does not decompress (e.g. a rawundici.requestwrapper) surfaces the compressed body as-iseither way
response.json()inexecuteTokenRequestthrowsSyntaxError: Unexpected token '\x1f'— the gzip magic byte, matching the reported stack trace.fix
1f 8b, RFC 1952), and transparently decompressed via the web-standardDecompressionStreambefore JSON parsing — runtime neutral (node 18+, browsers, workers), no node builtinsarrayBuffer(customfetchFnimplementations, test mocks) fall back tojson()/text()unchangedtests
four new tests: gzip body without
Content-Encoding(stripped-header case), gzip body withContent-Encoding(non-decompressing fetchFn case), gzip-compressed OAuth error response, and a plain-JSON realResponsecontrol. all written first and failing with the exactSyntaxErrorfrom the issue before the fix.client package tests (702), typecheck, and lint all pass. changeset included.