mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
Jude GaoandGitHub
4bb686dee9
### What? The behavior of `OPTIONS` requests differs depending on whether the page is an SSG page or not: - For **SSG pages**, we return a `405 Method Not Allowed` status code ([#34346](https://github.com/vercel/next.js/pull/34346)). - Otherwise, when an `OPTIONS` request reaches `doRender`, it returns a `400 Bad Request` ([#65295](https://github.com/vercel/next.js/pull/65295)). However, in the first case, handling the error page triggers a `doRender` call, which inadvertently resets the status code to `400`. We want to ensure it remains `405`. To fix this, I propose **skipping the error page rendering for `OPTIONS` requests on SSG pages** and directly returning `"Method Not Allowed"`. This also addresses several related issues (see "Why"). ### Why? When an `OPTIONS` request is made to an SSG page: 1. **Rendering an error page is wasteful.** A `405` response doesn’t need a UI, so skipping the rendering improves efficiency. 2. **The status code is reset incorrectly.** As described in ["What"], the logic in [`base-server.ts#L2682`](https://github.com/vercel/next.js/blob/canary/packages/next/src/server/base-server.ts#L2682) changes the status code to `400` when rendering an error page. 3. **It triggers a fatal error** (`Error: invariant: cache entry required but not generated`) for projects deployed on Vercel (see: [NEXT-4000](https://github.com/vercel/next.js/issues/4000)). ### How? Instead of rendering an error page, we return a **hardcoded HTML response** with a `"Method Not Allowed"` body. Closes [NEXT-4000](https://github.com/vercel/next.js/issues/4000).
7 lines
96 B
JavaScript
7 lines
96 B
JavaScript
/**
|
|
* @type {import('next').NextConfig}
|
|
*/
|
|
const nextConfig = {}
|
|
|
|
module.exports = nextConfig
|