Fork PR #96621 by @ceolinwill, re-opened as a branch PR so the "when
deployed" CI job can run — it requires Vercel deployment secrets that
GitHub does not expose to pull requests from forks, so it can never pass
on the original.
**The commit is unchanged and still authored by @ceolinwill.** Please
credit them; #96621 should be closed in favor of this one.
### What?
`getSharp()` calls `_sharp.block({ operation: ['VipsForeignLoad'] })` to
block every image loader, then unblocks a specific allowlist — and that
allowlist omitted `VipsForeignLoadSvg`. Because `_sharp` is a
module-level singleton, the block is process-wide and permanent: the
first `/_next/image` request in a process permanently disables Sharp's
SVG loader.
`ImageResponse` (`next/og`) rasterizes via resvg and then hands SVG to
Sharp, so once that loader is blocked it fails. The symptom is worse
than a bad image — the render throws `Input buffer contains unsupported
image format`, which surfaces as a **socket hang up / crashed response**
on any `ImageResponse` route requested after an uncached image
optimization in the same process.
Introduced by #96301, which aligned the Sharp allowlist with
`detectContentType()` but missed SVG.
Fixes#96612
### How?
Adds `'VipsForeignLoadSvg'` to the unblock list.
This does not weaken SVG protections for user-supplied images.
`detectContentType()` already returns SVG, and untrusted SVG is gated
separately by `dangerouslyAllowSVG`, which throws a 400 in
`imageOptimizer()` before Sharp is ever invoked. Unblocking the loader
only restores Sharp's ability to process SVG that Next.js itself
generates.
### Tests
The existing `og-api` test is extended to reproduce the exact
same-process ordering: render `/og-node`, perform an uncached
`/_next/image` optimization (asserting `x-nextjs-cache: MISS`, with a
random URL so it can't be served from cache), then render `/og-node`
again.
Verified locally that this fails without the one-line fix (`socket hang
up`, caused by `Input buffer contains unsupported image format`) and
passes with it.
No regressions in the SVG security coverage —
`test/e2e/image-optimizer/dangerously-allow-svg.test.ts` passes 94/94
including all `maintain vector svg` / blur-svg cases, and
`test/e2e/image-optimizer/image-optimizer.test.ts` plus the `og-*`
suites are green.
Co-authored-by: ceolinwill <4393133+ceolinwill@users.noreply.github.com>
The fixture's `next.config.js` had `output: 'standalone'` hardcoded,
which is meaningless on Vercel deployments (the standalone directory is
ignored) but became a build-time crash after #93684 made the Turbopack
NFT generator skip `next-server.js.nft.json` whenever an adapter is
configured. With `output: 'standalone'` still active,
`writeStandaloneDirectory` then fails with `ENOENT` when it tries to
read that file
([x-ref](https://github.com/vercel/next.js/actions/runs/26006483168/job/76441905221)).
This PR splits the `og-api` E2E suite into a default variant and a
`standalone.test.ts` wrapper that enables `output: 'standalone'` via the
`TEST_OUTPUT_STANDALONE` env var, and excludes the standalone wrapper
from the deploy test manifest.
The default variant still runs in `deploy` mode and preserves coverage
of `next/og` from Pages Router API routes, App Router route handlers
(edge and node), and middleware — paths not covered by the metadata-*
fixtures. The standalone variant continues to exercise the trace-copy
assertion in `next start` mode.
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
## What?
Converts existing `createNext()` usage into `nextTestSetup()`.
`createNext()` was the setup step we had before `nextTestSetup()` was
added.
This PR focused on the simple conversion cases. There will be a
follow-up to complete the last few.
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
- Change the Next manifest output assets to also track references to output assets there. That way, `page.js.nft.json` lists the referenced output assets of `page.js` and e.g. `page_client-reference-manifest.js` and all the chunks references in the manifest as well.
- For `ResolveResultItem::External`, continue resolving with a fresh `ModuleAssetContext` that doesn't have any of the build-time settings (because the Node environment when running the server won't have these settings either).
Closes PACK-3380
Closes PACK-3304
This was originally done in https://github.com/vercel/next.js/pull/63209
But I don't think this is correct.
Without this change, the added test fails with
```
Error: failed to pipe response
at pipeToNodeResponse (/next.js/packages/next/dist/server/pipe-readable.js:126:15)
at async handleRequest (/next.js/packages/next/dist/server/lib/router-server.js:275:24)
at async requestHandlerImpl (/next.js/packages/next/dist/server/lib/router-server.js:384:13)
at async Server.requestListener (/next.js/packages/next/dist/server/lib/start-server.js:142:13) {
[cause]: TypeError [ERR_INVALID_URL]: Invalid URL
at new NodeError (node:internal/errors:405:5)
at new URL (node:internal/url:676:13)
at /next.js/test/tmp/next-test-1729241452365-597/.next/server/edge/chunks/ssr/[project]_packages_next_dist_compiled_fd94e8._.js:31684:26 {
input: '/_next/static/media/noto-sans-v27-latin-regular.7e1666d1.ttf',
code: 'ERR_INVALID_URL'
}
}
```
(because the `blob:` prefix is missing for the font static URL)
Fixes the tests related to `config.regions` with Turbopack. There's
another case for Pages Router using edge runtime exporting the same
config. I'm going to implement that in a follow-up PR.
After implementing `regions` and making sure `wasm` and `assets` stay in
the manifest when empty (to pass another middleware test) I found that
`assets` was not implemented yet, causing the changes in this PR to fail
other tests related to `next/og` because that ships with a default font
file that it tries to load.
Since it was failing the PR and thus blocking the changes related to
`regions` I've implemented `assets` as well.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
This avoids the case that one can accidentally return a `Response` object in the Node.js runtime in `pages/api/`, that causes the request to hang forever.
<!--
Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change that you're making:
-->
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
fixes: #41395fixes: #42751.
This PR is a follow-up PR of [PR
43304](https://github.com/vercel/next.js/pull/43304).
This fix works by checking if the page is listed in
middleware-manifest.json's functions, if true then skip the
handleTraceFiles process. This also fixes the two issues aforementioned
by copying files listed in middleware-manifest.json for those pages.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This ensures we don't have a fatal error when not necessary and ensures
`@vercel/og` is working as expected.
x-ref: [slack
thread](https://vercel.slack.com/archives/CGU8HUTUH/p1667239940322769?thread_ts=1667238747.240989&cid=CGU8HUTUH)
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Luke Sandberg