v142 · miscellaneous

Stricter *+json MIME token validation for JSON modules

Reject JSON module script responses whose MIME type’s type or subtype contains non‑HTTP token code points (e.g. spaces) when matched via *+json; aligns with MIME Sniffing spec and other engines. This change is part of the Interop2025 modules focus area.

concepts

  1. Strict JSON MIME

    Type a Content-Type, see how Chrome ≤141 (lenient) versus Chrome 142+ (strict HTTP-token tokens) classifies it for JSON module imports.

  2. Charset, Parameters, Edge Cases

    The regression sheet the spec thread argued over: charset variants, quoted parameter values, whitespace, suffix forms. Live import() runs each MIME so the row's third badge is what your browser actually does.

  3. Server Config Doctor

    Eight real-world server Content-Type outputs (nginx, Apollo, OpenAPI, JSON-LD, vintage CMSes, misconfigured proxies) graded pass/fail against the strict tokenizer. Type your own and get a row-by-row verdict: type token, subtype token, +json suffix, parameter validity.

  4. Module Import Tester

    Paste a MIME type, pick an import assertion (type: "json" / css / none), and click "Test import" — the tool runs the tokenizer algorithm step-by-step, highlights the first invalid code point, and shows whether Chrome 142 would accept or reject the module. A side-by-side Chrome 141 vs 142 verdict table covers 12 common edge cases.

why it shipped

Without this change, developers must rely on inconsistent MIME sniffing behavior across browsers, which can lead to incorrect content handling. Aligning with the spec ensures predictable behavior and improves interoperability.

references