Skip to content

fix: strictly match decodeRequest content types#81

Merged
samlaycock merged 2 commits into
mainfrom
fix/decode-request-content-type
May 20, 2026
Merged

fix: strictly match decodeRequest content types#81
samlaycock merged 2 commits into
mainfrom
fix/decode-request-content-type

Conversation

@samlaycock

Copy link
Copy Markdown
Owner

Summary

  • Normalize the content-type header to the media type before parameters and compare supported types exactly.
  • Parse application/x-www-form-urlencoded bodies via URLSearchParams so mixed-case media types decode consistently across runtimes.
  • Add regression coverage for mixed-case supported types, parameterized URL-encoded content types, and invalid near-match content types.
  • Add a patch changeset.

Verification

  • bun fmt
  • bun run lint:fix
  • bun run lint
  • bun test
  • bun run typecheck

Closes #68

Normalize the request media type before matching supported decodeRequest content types.\n\nThis avoids rejecting valid mixed-case media types and prevents invalid near-match content types from being accepted by substring checks. URL-encoded request bodies are parsed directly with URLSearchParams so decoding does not depend on runtime content-type casing behavior.
@samlaycock samlaycock marked this pull request as ready for review May 20, 2026 06:34
@greptile-apps

greptile-apps Bot commented May 20, 2026

Copy link
Copy Markdown

Greptile Summary

This PR fixes decodeRequest to strictly match content-type media types instead of using substring inclusion, preventing near-match types like application/x-www-form-urlencodedx from being incorrectly accepted. It also normalizes the media type to lowercase before comparison so mixed-case values are handled consistently across runtimes.

  • src/decode.ts: Extracts the bare media type via split(\";\", 1)[0].trim().toLowerCase() and switches all three branches to strict equality; multipart/form-data uses a new withNormalizedContentType helper to reconstruct the request with a normalized header before calling .formData(), and application/x-www-form-urlencoded now uses URLSearchParams directly instead of .formData().
  • test/roundtrip.test.ts: Adds regression tests for parameterized url-encoded content types, mixed-case media type acceptance (all three supported types), and rejection of content types that merely contain a supported type as a substring.

Confidence Score: 5/5

Safe to merge — the changes are narrowly scoped to content-type matching and parsing, all three media-type branches are covered by new and existing tests, and the helper function correctly preserves original parameters when normalizing the header.

The logic change is straightforward: substring inclusion replaced with strict equality on a lowercased, parameter-stripped media type. The withNormalizedContentType helper correctly rebuilds the header while preserving parameters. Switching application/x-www-form-urlencoded to URLSearchParams is compatible with the decode function's Iterable signature. Regression coverage is thorough, including the previously flagged mixed-case multipart path.

No files require special attention.

Important Files Changed

Filename Overview
src/decode.ts Normalizes content-type to its bare media type before strict equality checks; adds withNormalizedContentType helper for multipart requests and switches url-encoded parsing to URLSearchParams.
test/roundtrip.test.ts Adds three new test cases: parameterized url-encoded content-type, mixed-case content-type acceptance (including Multipart/Form-Data), and rejection of near-match content-type substrings.
.changeset/strict-content-type-decoding.md New patch changeset entry for the content-type normalization fix.

Reviews (2): Last reviewed commit: "test: cover mixed-case multipart decode ..." | Re-trigger Greptile

Comment thread test/roundtrip.test.ts
Add regression coverage for mixed-case multipart/form-data content types.\n\nNormalize the multipart content-type passed to the platform formData parser while preserving parameters such as boundary, so decodeRequest handles mixed-case multipart headers consistently.
@samlaycock samlaycock merged commit 0bf221d into main May 20, 2026
3 checks passed
@samlaycock samlaycock deleted the fix/decode-request-content-type branch May 20, 2026 06:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[P1] Normalize and strictly match decodeRequest content types

1 participant