[miniflare] isCompressedByCloudflareFL does not normalise Content-Type case or whitespace

[chinesepowered]

What versions & operating system are you using?

Miniflare 4.20260722.0, Node v24.11.0, macOS 15 (Darwin 24.6.0). Also present on main @ 3a141ed11.

Please provide a link to a minimal reproduction

No repo needed — the reproduction is a direct call against the helper, included below.

Describe the Bug

isCompressedByCloudflareFL() decides whether Miniflare simulates Cloudflare's edge compression for a response. It compares the media type against an all-lowercase Set, but never normalises the incoming header:

// packages/miniflare/src/shared/mime-types.ts
export function isCompressedByCloudflareFL(
    contentTypeHeader: string | undefined | null
) {
    if (!contentTypeHeader) return true;

    const [contentType] = contentTypeHeader.split(";");

    return compressedByCloudflareFL.has(contentType);  // <-- not trimmed, not lowercased
}

Media types are case-insensitive (RFC 9110 §8.3.1), and optional whitespace is allowed before the ; that starts the parameter section. Both are mishandled:

isCompressedByCloudflareFL("text/html")               // true   (correct)
isCompressedByCloudflareFL("Text/HTML")               // false  (should be true)
isCompressedByCloudflareFL("text/html ; charset=utf-8") // false  (should be true)

Expected: the media type is trimmed and lowercased before lookup, so casing and optional whitespace do not change the result.

Why it matters: the practical effect is that a Worker returning Content-Type: Text/HTML (or with a space before the ;) gets different compression behaviour under wrangler dev than it does when deployed, since Cloudflare's edge treats the media type case-insensitively. That is a local-vs-production divergence, which is the specific thing Miniflare exists to avoid. The helper has two live call sites in the Miniflare response path.

Please provide any relevant error logs

No error is produced — the failure is silent and behavioural (compression is skipped when it should be applied).

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #14828

Summary

isCompressedByCloudflareFL() in Miniflare does not trim or lowercase the Content-Type media type before a case-sensitive Set lookup, so valid types like Text/HTML or text/html ; charset=utf-8 are misclassified as non-compressible — a local-vs-production divergence.

Classification

• Type: Bug
• Component: packages/miniflare
• Severity: Low
• Has Reproduction: Yes (inline function-level reproduction with concrete inputs/expected outputs)
• Quality: Complete

Findings

• Created: 2026-07-23
• Author: chinesepowered
• Version: Miniflare 4.20260722.0, Node v24.11.0, macOS 15 (Darwin 24.6.0); also reproduced on main @ 3a141ed11
• Labels: none
• Comments: 2

Analysis

• Component is clear: The bug is in packages/miniflare/src/shared/mime-types.ts, in isCompressedByCloudflareFL(), which determines whether Miniflare simulates Cloudflare edge compression for a response. This maps unambiguously to packages/miniflare.
• Root cause is well-identified: The media type is extracted via contentTypeHeader.split(";")[0] and looked up in an all-lowercase Set without .trim() or .toLowerCase(). Media types are case-insensitive per RFC 9110 §8.3.1, and optional whitespace is permitted before the ;.
• Reproducibility is strong: The reporter gives exact inputs and expected/actual results (Text/HTML → false, should be true; text/html ; charset=utf-8 → false, should be true). No external repo is required since it is a pure function.
• Impact is real but low severity: It affects response-compression parity between wrangler dev/Miniflare and deployed Workers only when a Worker emits non-canonical (mixed-case or space-padded) Content-Type headers. It is a fidelity/divergence bug, not a crash or data-loss issue, and most Workers emit canonical lowercase types.
• Fix is small and self-contained: Normalizing with .split(";")[0].trim().toLowerCase() before the Set lookup, plus a unit test covering casing and whitespace variants. The reporter notes there are two live call sites in the Miniflare response path.
• Reporter has a fix ready: In a follow-up comment, the reporter states they have a fix with a regression test and changeset (previously PR [miniflare] Match Content-Type case-insensitively for compression #14814, closed for lacking a linked issue) and offers to open a fresh PR linked to this issue.
• Verification note: The packages/ source tree is not present in this checkout, so the current source could not be confirmed directly; the assessment relies on the code snippet quoted in the issue. A maintainer should confirm against current source before merging.

Recommendation

Status: KEEP OPEN

Reasoning: This is a legitimate, clearly-scoped, well-reproduced bug with a correct standards-based rationale (RFC 9110 case-insensitivity). It is a small, actionable fix that improves local-vs-production parity, which is core to Miniflare's purpose, and the reporter already has a fix ready.

Action: Accept as a confirmed bug. Invite the reporter to open the fresh PR they mentioned, linked to this issue. The fix should normalize the media type (trim + lowercase) before the Set lookup in isCompressedByCloudflareFL(), add unit tests for mixed-case and whitespace-padded values, and verify both live call sites in the response path.

Suggested Labels: miniflare, bug

Suggested Comment

Thanks for the detailed report and the clear reproduction — this looks like a genuine bug. Media types are case-insensitive per RFC 9110 §8.3.1, and the ;-delimited parameter section can have surrounding whitespace, so we should trim and lowercase the media type before the Set lookup in isCompressedByCloudflareFL(). Please go ahead and open a fresh PR linked to this issue with your fix, regression test, and changeset — that would be very welcome. Appreciate you pinpointing the file and both call sites.

Structured summary (JSON)

{
  "issueNumber": 14828,
  "title": "isCompressedByCloudflareFL does not normalise Content-Type case or whitespace",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/14828",
  "recommendation": "KEEP OPEN",
  "difficulty": "easy",
  "reasoning": "Legitimate, well-reproduced Miniflare bug: the media type is not trimmed or lowercased before a case-sensitive Set lookup, so mixed-case or whitespace-padded Content-Type values are misclassified for edge compression simulation.",
  "suggestedAction": "Accept as a confirmed bug and invite the reporter to open their ready fix as a PR linked to this issue; normalize the media type (trim + lowercase) before the Set lookup in isCompressedByCloudflareFL(), add unit tests for casing and whitespace variants, and verify both live call sites.",
  "hasSuggestedComment": true,
  "suggestedLabels": ["miniflare", "bug"]
}

[chinesepowered]

Following up on my own report: I have a fix for this ready with a regression test and a changeset. It was previously up as #14814, which was closed for not having an issue attached — this issue is that missing piece, so I'm happy to open a fresh PR linked here if that's welcome.

The fix trims and lowercases the media type before the set lookup, so Text/HTML and text/html ; charset=utf-8 are treated the same way the edge treats them.