-
Notifications
You must be signed in to change notification settings - Fork 26.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: status code for 404 props queries to avoid client side navigation with empty props #60968
Merged
ijjk
merged 3 commits into
vercel:canary
from
Lezzio:fix/routing-with-middleware-empty-props-version-skew
Feb 5, 2024
Merged
fix: status code for 404 props queries to avoid client side navigation with empty props #60968
ijjk
merged 3 commits into
vercel:canary
from
Lezzio:fix/routing-with-middleware-empty-props-version-skew
Feb 5, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…n with empty props
Lezzio
requested review from
timneutkens,
ijjk,
shuding,
huozhi,
feedthejim,
ztanner and
wyattjoh
as code owners
January 22, 2024 12:20
Lezzio
changed the title
fix: status code for 404 props queries to avoid client side navigation with empty props
fix: status code 404 for props queries to avoid client side navigation with empty props
Jan 22, 2024
Lezzio
changed the title
fix: status code 404 for props queries to avoid client side navigation with empty props
fix: status code for 404 props queries to avoid client side navigation with empty props
Jan 23, 2024
Stats from current PRDefault BuildGeneral
Client Bundles (main, webpack)
Legacy Client Bundles (polyfills)
Client Pages
Client Build Manifests
Rendered Page Sizes
Edge SSR bundle Size
Middleware size
Next Runtimes
Diff detailsDiff for main-HASH.jsDiff too large to display |
ijjk
approved these changes
Feb 5, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! Went ahead and updated to handle some cases but seems good
1 task
inside
pushed a commit
to inside/repro-next-data-empty-object
that referenced
this pull request
Feb 7, 2024
The issue should be fixed according to this release: https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.37 and to this PR: vercel/next.js#60968 But testing the same workflow with v14.1.1-canary.37 doesn't fix it.
1 task
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Currently, when a middleware is active and the path results in a 404, the server responds with a 200 status code to data requests. We propose a change to ensure that a 404 status code is returned in these situations, as expected, solving production issues for the navigation router.
Why?
The client data requests (identified with
_next/data
path &x-nextjs-data
header) get answered the status code 200. The code below is executed when there is a version skew for the data requests (e.g prefetch in production).next.js/packages/next/src/server/lib/router-server.ts
Lines 217 to 227 in 4125069
The version skew consists in the client side version identified with the buildId in
__NEXT_DATA__
tag to be obsolete compared to the server version (BUILD_ID
file).In the case of prefetching, this leads to the code above being executed, therefore the
prefetch-reducer.ts
handles the response as valid and sets it in its cache. Which ultimately triggers a navigation with empty prop, resulting in erroneous behaviours reported in issues and in our production websites:next.js/packages/next/src/client/components/router-reducer/reducers/prefetch-reducer.ts
Lines 54 to 74 in 4125069
By switching the response to a 404, we trigger this code in the fetch (
fetchServerResponse
). This change prompts a hard navigation (mpaNavigation), effectively refreshing the client version and resynching it with the server version.next.js/packages/next/src/client/components/router-reducer/fetch-server-response.ts
Lines 125 to 134 in 4125069
How?
We simply update the status code to 404 here:
next.js/packages/next/src/server/lib/router-server.ts
Line 223 in 4125069
Closes: #60785
Closes: #59295
Fixes: #47516