fix: percent-encode X-Vinext-Params to allow non-ASCII route params

[southpolesteve]

Summary

• buildAppPageRscResponse was calling Headers.set("X-Vinext-Params", JSON.stringify(params)) with raw Unicode characters in the value
• The Fetch spec requires header values to be ByteStrings (each char ≤ U+00FF), so non-ASCII params (Korean, Japanese, etc.) caused a TypeError: Cannot convert argument to a ByteString
• Only RSC/client-side navigation was affected — direct SSR requests (buildAppPageHtmlResponse) never set this header

Fix

• Encode with encodeURIComponent when setting X-Vinext-Params in app-page-response.ts
• Decode with decodeURIComponent in both read sites in app-browser-entry.ts (initial hydration and client-side navigation)

Test

Added a unit test to tests/app-page-response.test.ts that verifies:

1. The header value is ASCII-safe after encoding
2. The params round-trip correctly through encode/decode

Closes #676

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vinext@677

commit: edc637b

[github-actions]

Example	Preview	Production	Original
app-router-cloudflare	preview	production
pages-router-cloudflare	preview	production
app-router-playground	preview	production	original
realworld-api-rest	preview	production
nextra-docs-template	preview	production
benchmarks	preview	production
hackernews	preview	production	original

[southpolesteve]

/bigbonk review please

[ask-bonk]

Clean, well-scoped fix. The diagnosis is correct: Headers.set() requires ByteString values (each char ≤ U+00FF per the Fetch spec), and JSON.stringify of non-ASCII params like Korean characters produces code points well above that limit.

What I verified:

1. All read/write sites are covered. There is exactly one write site (app-page-response.ts:172) and two read sites (app-browser-entry.ts:104 for initial hydration fallback, :243 for client-side navigation). All three are updated symmetrically with encodeURIComponent/decodeURIComponent.

2. No other consumers exist. Grepped the entire packages/vinext/src/ tree for Vinext-Params — only the three sites above. The generated entry code and prod server don't read this header directly.

3. The encoding choice is appropriate. encodeURIComponent produces only ASCII characters (letters, digits, and percent-encoded sequences), which trivially satisfies the ByteString constraint. It round-trips cleanly through decodeURIComponent.

4. Existing test updated correctly. The ASCII-params test now asserts the encoded form (encodeURIComponent('{"slug":"test"}')), and the new non-ASCII test validates both the ASCII-safety invariant and the encode/decode round-trip with Korean text.

5. Error handling is preserved. Both read sites already had try/catch blocks that gracefully handle malformed headers — decodeURIComponent on a corrupted value will throw, which falls into those existing catch blocks.

LGTM.

[ask-bonk]

Reviewed and approved PR #677. The fix is correct and complete:

• Root cause: Headers.set() requires ByteString values (chars ≤ U+00FF), but JSON.stringify of non-ASCII route params (Korean, Japanese, etc.) produces code points far above that limit, causing a TypeError.
• Fix: encodeURIComponent on write, decodeURIComponent on read — all three sites (1 write, 2 read) are updated symmetrically.
• Coverage: No other consumers of X-Vinext-Params exist in the codebase. The existing try/catch blocks at both read sites naturally handle any decodeURIComponent failures on corrupted values.
• Test: New test validates ASCII-safety of the encoded header value and round-trip correctness with Korean text. Existing test updated to assert the encoded form.

github run

[seoJing]

Ah, I was struggling with my local setup and just uploaded the PR, but I see you already fixed it! Thanks for the quick response. I'll close my PR.