Repository navigation
fix(client): accept xlsx workbooks mislabeled as JSON via ZIP magic sniff - #414
Merged
Merged
Conversation
FMP has labeled real workbooks as JSON (#411), causing getBinary to reject valid responses whose content type did not match the expected media types. Accept a body when it opens with the signature of one of the expected types, sniffing the ZIP magic bytes for xlsx and zip media types. JSON endpoints are never sniffed, so workbook signatures on JSON responses still fail as before. A JSON-labeled provider message keeps its provider-message error; every other rejected binary body is now summarized as a byte count and content type rather than echoed, preventing private payload bytes from leaking into error diagnostics.
FMP serves real XLSX workbooks under `application/json` (#411), which the strict content-type contract rejected. Binary endpoints now sniff the ZIP magic `PK\x03\x04` and accept a matching body under any content type, keeping the content type as received. The provider-message check still runs first, so a JSON error object such as `{"Error Message":...}` served on a binary endpoint is surfaced as a provider message rather than decoded as a workbook. Decode errors on binary endpoints now summarize the body as `<binary body omitted: N bytes, content-type ...>` so raw payload bytes never reach a diagnostic. JSON endpoints never sniff workbook signatures.
…ries Document the #411 change where FMP serves the real XLSX workbook under a JSON content type. The SDK now accepts a successful body that starts with the magic bytes of an expected format (XLSX and the ZIP family `PK\x03\x04`) regardless of its declared media type, keeping the content type exactly as received. `Content-Disposition` is not used for the decision and `application/octet-stream` is never sniffed. Record that every other error on a binary endpoint summarises the body (`<binary body omitted: N bytes, ...>`) instead of echoing raw bytes, and update the example comment to match. ADR 0002 cross-references ADR 0008 for the relaxed content-type policy. close #411
benbenbang
enabled auto-merge (rebase)
October 4, 2026 03:06
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.
FMP serves real XLSX workbooks under an
application/jsoncontent type (#411), which the strict content-type contract rejected, causing valid responses to fail. Binary endpoints now accept a body based on its actual signature rather than its declared media type, while keeping error diagnostics free of raw payload bytes.PK\x03\x04) on binary endpoints and accept a matching body under any content type, keeping the content type as received.Closes #411