Issue Station
Sign In
Tools hereToolbox

nextjs - ✅(Solved) Fix Manifest files (maybe others?) loaded via script tags with non-JavaScript content types [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#92180•Fetched 2026-04-08 02:01:53
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
1
Author
stuartkeithstuartkeith
Participants
stuartkeithstuartkeith
Timeline (top)
referenced ×2cross-referenced ×1issue_type_added ×1

Root Cause

Run the server and check the console - you will see (index):1 Refused to execute script from 'http://localhost:3000/_next/static/development/_clientMiddlewareManifest.js' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.

PR fix notes

PR #92219: fix(dev): return JS content type/body for turbopack middleware manifest in dev

Description (problem / solution / changelog)

What?

When handling dev middleware manifest requests in setup-dev-bundler, both:

  • /_next/static/development/_devMiddlewareManifest.json
  • /_next/static/development/_clientMiddlewareManifest.js

were returned as JSON (application/json) and with a JSON body.

For Turbopack, _clientMiddlewareManifest.js is loaded as a script and should be served as JavaScript. Under X-Content-Type-Options: nosniff, browsers can refuse to execute it when the MIME type is JSON.

Changes

  • add JAVASCRIPT_CONTENT_TYPE_HEADER constant
  • in setup-dev-bundler:
    • detect requests for devTurbopackMiddlewareManifestPath
    • set Content-Type: text/javascript; charset=utf-8 for .js manifest
    • return JS assignment body: self.__MIDDLEWARE_MATCHERS = ...; self.__MIDDLEWARE_MATCHERS_CB && self.__MIDDLEWARE_MATCHERS_CB()
    • keep existing JSON response for _devMiddlewareManifest.json

Why

This aligns runtime behavior with how the Turbopack client middleware manifest is consumed and fixes strict MIME type failures in dev.

Fixes #92180

Changed files

  • packages/next/src/lib/constants.ts (modified, +1/-0)
  • packages/next/src/server/lib/router-utils/setup-dev-bundler.ts (modified, +23/-2)

PR #92905: fix(dev): serve _clientMiddlewareManifest.js with text/javascript content type

Description (problem / solution / changelog)

Summary

The Turbopack client middleware manifest (_clientMiddlewareManifest.js) is a JavaScript file (contains self.__MIDDLEWARE_MATCHERS = ...) that is loaded via a <script> tag. However, it was being served with application/json; charset=utf-8 content type.

When X-Content-Type-Options: nosniff is set (e.g. by a proxy), Chrome refuses to execute the script because its MIME type is not executable.

Fix

  • Add JAVASCRIPT_CONTENT_TYPE_HEADER constant to packages/next/src/lib/constants.ts
  • Split the combined manifest handler in setup-dev-bundler.ts to serve _devMiddlewareManifest.json with JSON content type and _clientMiddlewareManifest.js with text/javascript content type

Fixes #92180

Changed files

  • packages/next/src/lib/constants.ts (modified, +1/-0)
  • packages/next/src/server/lib/router-utils/setup-dev-bundler.ts (modified, +14/-4)

Code Example

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Fri Feb 27 19:31:41 PST 2026; root:xnu-11417.140.69.709.8~1/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 24.14.0
  npm: 11.9.0
  Yarn: N/A
  pnpm: 10.3.0
Relevant Packages:
  next: 16.2.1-canary.16 // Latest available version is detected (16.2.1-canary.16).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.9.3
Next.js Config:
  output: N/A
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://github.com/stuartkeith/next-header-reproduction

To Reproduce

(I encountered this while using a proxy that adds headers like x-content-type-options: nosniff. The reproduction doesn't bother with a real proxy, just adds a header that causes the problem).

Run the server and check the console - you will see (index):1 Refused to execute script from 'http://localhost:3000/_next/static/development/_clientMiddlewareManifest.js' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.

<img width="1826" height="324" alt="Image" src="https://github.com/user-attachments/assets/27422124-e6e1-4377-9934-312ca3757e83" />

Current vs. Expected behavior

In Chrome (and maybe other browsers), "strict MIME type checking" can come into play - for me, it was because a proxy was adding a X-Content-Type-Options: nosniff header.

This causes Chrome to be stricter about content types. It will then not execute the _clientMiddlewareManifest.js script (and maybe others?), because the content type is application/json; charset=utf-8. Because it's loaded via a script tag, it's expected the file's content type is JavaScript, not JSON.

I think the expected behaviour would be for the script tag to be text/javascript, so the script executes.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Fri Feb 27 19:31:41 PST 2026; root:xnu-11417.140.69.709.8~1/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 24.14.0
  npm: 11.9.0
  Yarn: N/A
  pnpm: 10.3.0
Relevant Packages:
  next: 16.2.1-canary.16 // Latest available version is detected (16.2.1-canary.16).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Not sure

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

This is new in Next 16.2.x. I can see there is a constant for the content type used in a few places, so this might apply in other scenarios too.

extent analysis

TL;DR

The issue can be resolved by ensuring the correct MIME type is set for the _clientMiddlewareManifest.js script, which is currently being served as application/json instead of text/javascript.

Guidance

  • Verify that the server is correctly setting the Content-Type header for the _clientMiddlewareManifest.js script. It should be set to text/javascript instead of application/json.
  • Check the Next.js configuration to see if there are any settings that can be adjusted to set the correct MIME type for the script.
  • Consider adding a custom header to the server response to override the Content-Type header set by the proxy.
  • Test the application in different browsers to see if the issue is specific to Chrome or if it occurs in other browsers as well.

Example

No code snippet is provided as the issue is related to the server configuration and MIME type settings.

Notes

The issue seems to be specific to Next

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#request error#file not found#serialization error#model compatibility#GPU setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING