fix: base64-encode x-partykit-props header for ASCII safety#407
Merged
Conversation
Props containing non-ASCII characters (e.g. accented names like
"Usuário") were written into the x-partykit-props header verbatim,
triggering workerd's "header value contains non-ASCII characters"
warning and a TypeError in browser fetch implementations.
Encode the header as UTF-8 base64 when writing and decode it on the
server. Raw-JSON values from older callers are still accepted for
backwards compatibility (base64 never starts with { or [).
Fixes cloudflare/agents#1751
Co-authored-by: Cursor <cursoragent@cursor.com>
🦋 Changeset detectedLatest commit: 4359968 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
hono-party
partyfn
partyserver
partysocket
partysub
partysync
partytracks
partywhen
y-partyserver
commit: |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Props passed to
getServerByName/routePartykitRequest(and, transitively, the Agents SDK'sgetAgentByName/routeAgentRequest) are serialized into thex-partykit-propsrequest header. The header value was set viaJSON.stringify(props)directly, so any non-ASCII characters in props (e.g. accented names like"Usuário", CJK text, emoji) produced a non-ASCII header value. workerd tolerates this as a UTF-8 quirk but emits a warning, and the same call throws aTypeErrorin browserfetchimplementations.This encodes the header as UTF-8 → base64 when writing and decodes it back on the server, so the header value is always ASCII while the original Unicode payload round-trips intact.
encodeProps— UTF-8 encode the JSON, then base64.decodeProps— base64-decode back to the original Unicode. For backwards compatibility with stubs/requests created by older versions, it detects raw-JSON values (a leading{/[, which base64 can never produce) and parses them directly.Fixes cloudflare/agents#1751.
Test plan
/unicode-props-parties/route delivers{ secret: "Usuário 日本語 🎉" };PropsServerechoes back the rawx-partykit-propsheader. The test asserts props round-trip and that the header value the DO receives is ASCII-only (/^[\x00-\x7f]*$/). It fails on the oldJSON.stringifybehavior and passes with the fix.npm run check:lintandnpm run check:typeclean;npm run formatapplied.patchchangeset.Made with Cursor