This new option specifies a list of host names that are considered safe, to accept as Server Action requests if they're different from the initial request origin. It can be very helpful when the hosted app has many layers of reverse proxies ahead.
Closes#57397.
### What?
Follow-up of #56797
While working on this, I noticed that some logic around stripping internal headers was duplicated, so I did some cleanup too.
### Why?
In #56797 we set these headers, but it only affected Route Handlers, Middleware is still missing them, which is a regression introduced in #52492
(Related: https://github.com/vercel/next-learn/issues/252)
### How?
Move to set these headers up to `base-server.ts` so they are present in Middleware too.
> Note: All headers are set with `??=` to respect the original value if set (with other words, only add these headers if they aren't set yet)
Closes NEXT-
Fixes#52266
We noticed that our internal soft tags were unexpectedly including the query string for SSR routes which causes the URL soft tag to not match correctly so this ensures we properly normalize the value to just the pathname and not include the query.
I think that sometimes when a revalidation happens from a request with
caching headers this causing the 304 status to be cached.
This PR ensures the 304 from an initial response doesn't affect a
background revalidation.
Fixes: https://github.com/vercel/next.js/issues/56580
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
[1] Simplify example
[2] Refactor `delete` method to use `cookies.set`
### Why?
[1] Make it easier to follow
[2] Fix build errors
### How?
[1] Adding comments and abstracting code into helper functions
[2] Setting cookie to empty value when removed
---------
Co-authored-by: Lee Robinson <me@leerob.io>
You can read the removed comments to get some context here. Based on the community feedback, we're removing this compile-time error and instead, it will be a runtime error only when it gets accessed by React and found it missing in the manifest.
In the future, we'll need:
- Converting the client references created this way to be specific errors. So they'll only throw in that certain case.
- Or have a prepass compilation to collect all the references globally. This way we can support any kind of layer change.
Related: https://twitter.com/trashh_dev/status/1719016700191150550.
Hi,
I added a key in the map iteration of scripts in Youtube Embed. I use the index as a key but maybe there are a better solution about this like script.url + index 🤔
There isn't open related issues with this PR as this moment.
```js
{scripts?.map((script, index) => (
<Script
key={index}
src={script.url}
strategy={scriptStrategy[script.strategy] as ScriptProps['strategy']}
stylesheets={stylesheets}
/>
))}
```
### What?
This PR adds an hourly workflow that will update the test manifest used when testing with Turbopack.
### Why?
To ensure we don't regress any test suites.
### How?
I use the existing `scripts/update-fonts-data-workflow.js` workflow script which will execute a script, then create a PR with the current working tree. If any pending automated PRs exist, they will be closed when a new one is opened.
Stumbled upon this while investigating. The previous configuration did not make a lot of sense.
On Node, fs reads can be expensive so it's best to avoid them as much as possible. The current configuration would create chunks eagerly for nothing, leading to sub optimal perf.
The only reason we want chunk on the server is to avoid reloading common parts between entrypoints, so I'm changing the config to reflect that.
This PR sets up the webpack build workers (webpackBuildWorker: true) to serialize debug trace information across the worker boundary so that it can appear in the final .next/trace file at the end of the build.
Currently, when webpackBuildWorker is turned on, all traces that appear under the webpack compilation are lost. After this PR, they will appear in the trace file just like when the workers are not enabled.
For app router bundling layers "SSR rendering" and "browser" layer, which are used for server side rendering and client, we should still apply the module resolving rules to all assets since we bundled everything, removed the default exclude conditions as they'll not apply the rules to node_modules. That could cause the mismatch resolving for package.
E.g. You have two dual packages A and B are both compatible for ESM and CJS, and both have default export. B is depent on A, but when you import B in a client component that will be SSR'd, it's picking up the CJS asset like the case described in #57584 .
Fixes#57584
Closes NEXT-1702
### What?
Wraps up metadata-dynamic-routes tests fixes for the turbopack. There is 1 remaining failing test due to lacks of supporting `import.meta.url` which need to be addressed separately.
I spent amount of time why turbopack cannot find the route for the dynamic metadata for a certain route. In the end, found there are mismatching expectations for the route due to different hash for the certain route. We do use the same djb2 hash between next.js and turbopack both, so it was quite confusing why we don't get deterministic hash.
After trying some experiments, found out root cause was how 2 different runtimes handle overflow for given type of numbers. In rust + turbpack we use u32 and do 32-bit hash calculation for given string, while in js we implicitly used number type as is, in result overflow occurs with default 53-bit float.
Originally I tried to adjust hash in turbopack side to preserve js hash as-is, but so far I found it was non trivial to do so as rust there's no out of the box types we can coerce to the js number type. In result, unlike other fixes in turbopack this PR changes how js hash is being generated. I hope this woulndn't be a breaking changes; expect so since this is a metadata specific hash that we do not have written spec for it.
Closes WEB-1890
### What?
If the version of `autoprefixer` is 10.0.0 and the version of `tailwindcss` is less than 3.3.0, the error `RangeError: Maximum call stack size exceeded` occurs when you create with tailwindcss & typescript and run it.
### Why?
The exact reason is unknown, but it appears to be a compatibility issue. Also, currently configuring tailwindcss with ts makes the tailwind config file in ts, which is supported since tailwindcss version 3.3.0. (In js, it works even if you set the version of `autoprefixer` to 10.0.1 and lower the version of tailwindcss.)
### How?
Simply default the minimum version of `autoprefixer` to 10.0.1 and the minimum version of `tailwindcss` to 3.3.0.
### What?
Previously the matching just used the last match for children which could lead to empty groups or groups without page matches overriding the actual page.
This PR makes sure this doesn't happen and emits an issue (which unfortunately doesn't get displayed yet) in case there are 2 `page` matches which would go into the children slot.
Closes WEB-1895
This removes the ignores for dev react bundles which was added as an
optimization but causes issues when react is imported from an ESM module
since all requires are being analyzed for named exports.
Fixes#57582
Displaying hints of "missing default export" if you didn't properly export the `default` handler for og image
```
▲ Next.js 14.0.1-canary.2
- Local: http://localhost:3000
✓ Ready in 1089ms
✓ Compiled /opengraph-image/[[...__metadata_id__]]/route in 211ms (44 modules)
⨯ Error: Default export is missing in "/Users/huozhi/workspace/next.js/test/e2e/app-dir/metadata-dynam
ic-routes/app/opengraph-image.tsx"
at eval (webpack:///app/opengraph-image.tsx?3407:11:1)
at (app-metadata-route)/../../../../packages/next/dist/build/webpack/loaders/next-metadata-route-lo
ader.js?page=%2Fopengraph-image%2F%5B%5B...__metadata_id__%5D%5D%2Froute&isDynamic=1!./app/opengraph-im
age.tsx?__next_metadata_route__ (/Users/huozhi/workspace/next.js/test/e2e/app-dir/metadata-dynamic-rout
es/.next/server/app/opengraph-image/[[...__metadata_id__]]/route.js:362:1)
at __webpack_require__ (/Users/huozhi/workspace/next.js/test/e2e/app-dir/metadata-dynamic-routes/.n
ext/server/webpack-runtime.js:33:42)
```