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 encoding error with location and refresh headers #27003
fix encoding error with location and refresh headers #27003
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hi, do you plan to merge current canary and fix test suites? We are experiencing same problem with |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hi, that looks like some tests are still failing ( |
This comment has been minimized.
This comment has been minimized.
Failing test suitesCommit: 1447ec4 test/e2e/basepath.test.ts
Expand output● basePath › should use urls with basepath in router events for hash changes
● basePath › should use urls with basepath in router events for cancelled routes
● basePath › should use urls with basepath in router events for failed route change
|
Hi, thank you for your changes. The test results with fixed |
I was hoping your PR will fix my issue, but I was wrong 😄 Your last comment pointed me into right direction. Thank you. (I created a new issue.) |
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.
Looks good to me, thanks!
This comment has been minimized.
This comment has been minimized.
@styfle Thanks for the review! I fixed the merge conflicts, the other day. Feel free to take this long running PR across the finish line when you get a chance 🙏 |
Stats from current PRDefault Build (Increase detected
|
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
buildDuration | 21.6s | 22.2s | |
buildDurationCached | 4.5s | 4.3s | -130ms |
nodeModulesSize | 336 MB | 336 MB |
Page Load Tests Overall increase ✓
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
/ failed reqs | 0 | 0 | ✓ |
/ total time (seconds) | 3.498 | 3.647 | |
/ avg req/sec | 714.63 | 685.58 | |
/error-in-render failed reqs | 0 | 0 | ✓ |
/error-in-render total time (seconds) | 1.736 | 1.69 | -0.05 |
/error-in-render avg req/sec | 1440.01 | 1478.95 | +38.94 |
Client Bundles (main, webpack, commons)
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
450.HASH.js gzip | 179 B | 179 B | ✓ |
framework-HASH.js gzip | 42.2 kB | 42.2 kB | ✓ |
main-HASH.js gzip | 28.3 kB | 28.3 kB | ✓ |
webpack-HASH.js gzip | 1.45 kB | 1.45 kB | ✓ |
Overall change | 72.2 kB | 72.2 kB | ✓ |
Legacy Client Bundles (polyfills)
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
polyfills-HASH.js gzip | 31 kB | 31 kB | ✓ |
Overall change | 31 kB | 31 kB | ✓ |
Client Pages
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
_app-HASH.js gzip | 1.37 kB | 1.37 kB | ✓ |
_error-HASH.js gzip | 194 B | 194 B | ✓ |
amp-HASH.js gzip | 312 B | 312 B | ✓ |
css-HASH.js gzip | 327 B | 327 B | ✓ |
dynamic-HASH.js gzip | 2.38 kB | 2.38 kB | ✓ |
head-HASH.js gzip | 350 B | 350 B | ✓ |
hooks-HASH.js gzip | 635 B | 635 B | ✓ |
image-HASH.js gzip | 4.44 kB | 4.44 kB | ✓ |
index-HASH.js gzip | 263 B | 263 B | ✓ |
link-HASH.js gzip | 1.87 kB | 1.87 kB | ✓ |
routerDirect..HASH.js gzip | 321 B | 321 B | ✓ |
script-HASH.js gzip | 383 B | 383 B | ✓ |
withRouter-HASH.js gzip | 318 B | 318 B | ✓ |
85e02e95b279..7e3.css gzip | 107 B | 107 B | ✓ |
Overall change | 13.3 kB | 13.3 kB | ✓ |
Client Build Manifests
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
_buildManifest.js gzip | 460 B | 460 B | ✓ |
Overall change | 460 B | 460 B | ✓ |
Rendered Page Sizes
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
index.html gzip | 523 B | 523 B | ✓ |
link.html gzip | 536 B | 536 B | ✓ |
withRouter.html gzip | 517 B | 517 B | ✓ |
Overall change | 1.58 kB | 1.58 kB | ✓ |
Default Build with SWC (Decrease detected ✓)
General Overall increase ⚠️
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
buildDuration | 23.4s | 23.2s | -213ms |
buildDurationCached | 4.4s | 4.3s | -22ms |
nodeModulesSize | 336 MB | 336 MB |
Page Load Tests Overall decrease ⚠️
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
/ failed reqs | 0 | 0 | ✓ |
/ total time (seconds) | 3.617 | 3.61 | -0.01 |
/ avg req/sec | 691.13 | 692.54 | +1.41 |
/error-in-render failed reqs | 0 | 0 | ✓ |
/error-in-render total time (seconds) | 1.642 | 1.804 | |
/error-in-render avg req/sec | 1522.62 | 1385.45 |
Client Bundles (main, webpack, commons)
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
450.HASH.js gzip | 179 B | 179 B | ✓ |
framework-HASH.js gzip | 42.3 kB | 42.3 kB | ✓ |
main-HASH.js gzip | 28.5 kB | 28.5 kB | ✓ |
webpack-HASH.js gzip | 1.44 kB | 1.44 kB | ✓ |
Overall change | 72.5 kB | 72.5 kB | ✓ |
Legacy Client Bundles (polyfills)
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
polyfills-HASH.js gzip | 31 kB | 31 kB | ✓ |
Overall change | 31 kB | 31 kB | ✓ |
Client Pages
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
_app-HASH.js gzip | 1.35 kB | 1.35 kB | ✓ |
_error-HASH.js gzip | 180 B | 180 B | ✓ |
amp-HASH.js gzip | 305 B | 305 B | ✓ |
css-HASH.js gzip | 321 B | 321 B | ✓ |
dynamic-HASH.js gzip | 2.38 kB | 2.38 kB | ✓ |
head-HASH.js gzip | 342 B | 342 B | ✓ |
hooks-HASH.js gzip | 622 B | 622 B | ✓ |
image-HASH.js gzip | 4.46 kB | 4.46 kB | ✓ |
index-HASH.js gzip | 256 B | 256 B | ✓ |
link-HASH.js gzip | 1.91 kB | 1.91 kB | ✓ |
routerDirect..HASH.js gzip | 314 B | 314 B | ✓ |
script-HASH.js gzip | 375 B | 375 B | ✓ |
withRouter-HASH.js gzip | 309 B | 309 B | ✓ |
85e02e95b279..7e3.css gzip | 107 B | 107 B | ✓ |
Overall change | 13.2 kB | 13.2 kB | ✓ |
Client Build Manifests
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
_buildManifest.js gzip | 460 B | 460 B | ✓ |
Overall change | 460 B | 460 B | ✓ |
Rendered Page Sizes
vercel/next.js canary | jamsinclair/next.js fix-location-header-invalid-char | Change | |
---|---|---|---|
index.html gzip | 524 B | 524 B | ✓ |
link.html gzip | 535 B | 535 B | ✓ |
withRouter.html gzip | 517 B | 517 B | ✓ |
Overall change | 1.58 kB | 1.58 kB | ✓ |
This comment has been minimized.
This comment has been minimized.
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.
Just verified this and it looks good, thanks 💯
Fixes the merge conflicts in vercel#27003 Fixes vercel#24977 Fixes vercel#24047 Closes vercel#27003 Co-Authored-By: Jamie <5964236+jamsinclair@users.noreply.github.com>
Thanks @jamsinclair! I've opened #33763 where the merge conflict is solved. Added you as co-author ofcourse 👍 |
Fixes the merge conflicts in #27003 Fixes #24977 Fixes #24047 Closes #27003 Co-Authored-By: Jamie <5964236+jamsinclair@users.noreply.github.com> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have 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 helpful link attached, see `contributing.md` ## Documentation / Examples - [ ] Make sure the linting passes by running `yarn lint`
Fixes the merge conflicts in vercel#27003 Fixes vercel#24977 Fixes vercel#24047 Closes vercel#27003 Co-Authored-By: Jamie <5964236+jamsinclair@users.noreply.github.com> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have 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 helpful link attached, see `contributing.md` ## Documentation / Examples - [ ] Make sure the linting passes by running `yarn lint`
Bug
fixes #number
Edit: Looks like this may've been a regression of #17907?
Minimal reproduction with a next app: https://github.com/jamsinclair/nextjs-refresh-header-bug
Redirected URLs with search param keys containing characters outside of the default ASCII and utf-8 encodings would throw a server 500 error.
e.g. a redirect URL with
/?テスト
would error.The errors serverside were either:
TypeError [ERR_INVALID_CHAR]: Invalid character in header content ["Location"]
orTypeError [ERR_INVALID_CHAR]: Invalid character in header content ["Refresh"]
Solution
The issue arose as we were only re-encoding the search param values and not the keys.
next.js/packages/next/server/next-server.ts
Lines 866 to 870 in b6c590b
Updating the stringify method to also encode the search param keys seems to have resolved the issue.
For the future, it may be worth enforcing stricter assumptions around search params and standardising everywhere with the
URLSearchParams
interface. Not confident I can lead that refactor 😅