nextjs - ✅(Solved) Fix App crashes on POST requests with `Origin: null` + `Content-Type: application/x-www-form-urlencoded` headers [2 pull requests, 1 comments, 2 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#84786Fetched 2026-04-08 02:18:21
View on GitHub
Comments
1
Participants
2
Timeline
11
Reactions
7
Author
Timeline (top)
labeled ×4cross-referenced ×2closed ×1commented ×1

Error Message

TypeError: Invalid URL at new URL (node:internal/url:818:25) at handleAction at renderToHTMLOrFlightImpl

Root Cause

Server crashes with

TypeError: Invalid URL
at new URL (node:internal/url:818:25)
at handleAction
at renderToHTMLOrFlightImpl

I think he's trying to create a new URL(“null”) that isn't handled correctly, because he doesn't expect to receive this value, even though it is valid.

Fix Action

Fixed

PR fix notes

PR #84798: fix: Handle null Origin string value as per RFC 6454

Description (problem / solution / changelog)

Fixes: https://github.com/vercel/next.js/issues/84786

This RFC lists a couple of cases in which Origin: null is expected.

Whenever a user agent issues an HTTP request from a "privacy-sensitive" context, the user agent MUST send the value "null" in the Origin header field.

Note that as per user report, they only observe this in Firefox, under special circumstances, and that:

Chromium browsers don't modify the header.

Changed files

  • packages/next/src/server/app-render/action-handler.ts (modified, +13/-4)

PR #85402: Handle Origin: null headers

Description (problem / solution / changelog)

Closes https://linear.app/vercel/issue/NEXT-4752 Closes https://github.com/vercel/next.js/issues/84786

Origin: null is valid per spec: https://www.rfc-editor.org/rfc/rfc6454#section-7.3

The original issue description is a bit sus to me. But then it's probably just good discipline to handle valid spec values.

Changed files

  • packages/next/src/server/app-render/action-handler.ts (modified, +3/-2)
  • packages/next/src/server/lib/router-utils/block-cross-site.ts (modified, +1/-1)
  • test/e2e/app-dir/actions-allowed-origins/app-action-allowed-origins.test.ts (modified, +13/-0)

Code Example

curl -X POST 'http://localhost:3000/' \
  -H 'Origin: null' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Sec-Fetch-Site: same-origin'

---

TypeError: Invalid URL
at new URL (node:internal/url:818:25)
at handleAction
at renderToHTMLOrFlightImpl

---

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:29:54 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T8122
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 22.17.1
  npm: 10.9.2
  Yarn: N/A
  pnpm: 10.18.2
Relevant Packages:
  next: 16.0.0-canary.2 // Latest available version is detected (16.0.0-canary.2).
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.3
Next.js Config:
  output: N/A
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/github/vercel/next.js/tree/canary/examples/reproduction-template

To Reproduce

  1. Create a basic Next.js app (reproductible with the reproduction-template without changes)
  2. Send a POST request to any page with these specific headers:
    • Origin: null
    • Content-Type: application/x-www-form-urlencoded
curl -X POST 'http://localhost:3000/' \
  -H 'Origin: null' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Sec-Fetch-Site: same-origin'
  1. You'll get an Internal Server Error

Reproducible locally and on production sites

Current vs. Expected behavior

Current behavior :

Server crashes with

TypeError: Invalid URL
at new URL (node:internal/url:818:25)
at handleAction
at renderToHTMLOrFlightImpl

I think he's trying to create a new URL(“null”) that isn't handled correctly, because he doesn't expect to receive this value, even though it is valid.

Expected behavior: Next.js should handle origin: null gracefully, as this is a valid value per RFC 6454 Section 7.3.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:29:54 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T8122
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 22.17.1
  npm: 10.9.2
  Yarn: N/A
  pnpm: 10.18.2
Relevant Packages:
  next: 16.0.0-canary.2 // Latest available version is detected (16.0.0-canary.2).
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.3
Next.js Config:
  output: N/A

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

Error Handling, Headers

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

next dev (local), next start (local), Other (Deployed), Vercel (Deployed)

Additional context

Also reproduced on production sites with Next 15.3 and 15.4

To provide some context on how this bug was discovered: Our users were complaining about 500 errors on some browsers (particularly Firefox) when visiting the site for the first time.

Our site is temporarily under a Cloudflare Challenge. Once the challenge is successful, Cloudflare redirects to the site via a POST request with the challenge result in the body.

If the user goes to the site, they are redirected to their locale (e.g., / to /en). What happens with the Cloudflare challenge is that there will be a POST / -> 307 Temporary Redirect when the challenge is succeded, then a POST /en -> 500 Internal Server Error on Firefox <img width="450" height="53" alt="Image" src="https://github.com/user-attachments/assets/b7c5164e-5cac-4841-97ee-d5d24fb3fbd8" />

This happens because Firefox, as a security measure and in accordance with the RFC, will modify the header Origin: mywebsite.com to Origin: null during the second POST request that was redirected. Chromium browsers don't modify the header. <img width="186" height="24" alt="Image" src="https://github.com/user-attachments/assets/62ffb0d8-9978-4152-bae5-5b376c0349f5" />

So I think that sites using a Cloudflare challenge, with a user who uses a Firefox browser, may encounter this problem.

This error occurs exclusively when these two headers are sent together in the request.

<sub>NEXT-4752</sub>

extent analysis

TL;DR

The issue can be fixed by handling the Origin: null header in Next.js to prevent it from crashing when receiving a POST request with this header and Content-Type: application/x-www-form-urlencoded.

Guidance

  1. Verify the issue: Reproduce the issue using the provided curl command to ensure the problem is consistent.
  2. Check Next.js documentation: Review the Next.js documentation to see if there are any configuration options or middleware that can handle the Origin: null header.
  3. Implement a custom middleware: Create a custom middleware function to handle the Origin: null header and prevent the server from crashing.
  4. Test with different browsers: Test the fix with different browsers, including Firefox, to ensure the issue is resolved.

Example

// Example of a custom middleware function to handle Origin: null header
const handleOriginNull = (req, res, next) => {
  if (req.headers.origin === 'null') {
    // Handle the null origin header
    req.headers.origin = '';
  }
  next();
};

Notes

The issue seems to be specific to Next.js and the way it handles the Origin: null header. The provided example is a minimal illustration and might need adjustments based on the actual Next.js version and configuration.

Recommendation

Apply a workaround by implementing a custom middleware function to handle the Origin: null header, as the issue seems to be related to how Next.js handles this specific header.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING