next.js

4bb686de - Fix: respond 405 status code on OPTIONS request to SSG page (#76767)

Fix: respond 405 status code on OPTIONS request to SSG page (#76767) ### 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).