Encode non-ASCII characters in cache tags at construction#93601
Merged
Conversation
Contributor
Tests PassedCommit: 0f96095 |
8606599 to
f9de323
Compare
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
gnoff
approved these changes
May 7, 2026
gnoff
left a comment
Contributor
There was a problem hiding this comment.
I think this is landable but we should consider perturbing encoded keys so they cannot be matched synonymous key inputs
Contributor
Author
When a cache tag contains a non-ASCII character (Hebrew, CJK, emoji, …) it gets written into the internal `x-next-cache-tags` HTTP header on ISR responses. Node's `validateHeaderValue` rejects any byte outside `\t\x20-\x7e`, so the response crashes with `ERR_INVALID_CHAR`. On Vercel deploys stale-if-error masks the 500 from clients, but revalidation itself keeps failing and the cache stops refreshing for affected routes. This change introduces a single `encodeCacheTag` helper and applies it at every public boundary — `validateTags` (which `cacheTag()`, `unstable_cache()`, and `fetch` tags all funnel through), `getImplicitTags` for path-derived tags, and `revalidatePath` / `revalidateTag` / `updateTag` for invalidation inputs. The encoder matches runs of out-of-class code units so surrogate pairs reach `encodeURIComponent` intact, and it is idempotent on already-encoded `%xx` sequences, so callers can pass either the raw or the encoded form interchangeably. PR #93139 already encodes path-derived tags at construction, but it misses every user-supplied tag entry point and uses a `decodeURIComponent` round-trip that silently mangles literal `%xx` characters in tag values. PR #93167 encodes only at the `setHeader` sites, which leaves storage and invalidation diverging and requires every new write site to remember the encoding step. The canonical-form-at-the-boundary approach taken here covers all entry points and keeps storage, comparison, and the wire in sync. fixes #93142 closes #93139 closes #93167 Co-authored-by: Swarnava Sengupta <swarnava.sengupta@vercel.com> Co-authored-by: Or Nakash <ornakash@gmail.com>
f9de323 to
0f96095
Compare
3 tasks
james-elicx
added a commit
to cloudflare/vinext
that referenced
this pull request
May 8, 2026
Tags with non-ASCII characters (Hebrew, Arabic, CJK, emoji) can crash ISR responses with ERR_INVALID_CHAR when written to x-next-cache-tags, and silently break invalidation when storage form diverges from the form revalidateTag/revalidatePath produce. Add encodeCacheTag/encodeCacheTags helper (matches behavior of vercel/next.js#93601) and apply it at every public boundary: cacheTag, revalidateTag, revalidatePath, updateTag, unstable_cache options.tags, fetch next.tags, and the path-derived _N_T_ tag builders. Closes #1138
james-elicx
added a commit
to cloudflare/vinext
that referenced
this pull request
May 8, 2026
…#1143) Tags with non-ASCII characters (Hebrew, Arabic, CJK, emoji) can crash ISR responses with ERR_INVALID_CHAR when written to x-next-cache-tags, and silently break invalidation when storage form diverges from the form revalidateTag/revalidatePath produce. Add encodeCacheTag/encodeCacheTags helper (matches behavior of vercel/next.js#93601) and apply it at every public boundary: cacheTag, revalidateTag, revalidatePath, updateTag, unstable_cache options.tags, fetch next.tags, and the path-derived _N_T_ tag builders. Closes #1138
unstubbable
added a commit
that referenced
this pull request
May 18, 2026
When a cache tag contains a non-ASCII character (Hebrew, CJK, emoji, …) it gets written into the internal `x-next-cache-tags` HTTP header on ISR responses. Node's `validateHeaderValue` rejects any byte outside `\t\x20-\x7e`, so the response crashes with `ERR_INVALID_CHAR`. On Vercel deploys stale-if-error masks the 500 from clients, but revalidation itself keeps failing and the cache stops refreshing for affected routes. This change introduces a single `encodeCacheTag` helper and applies it at every public boundary — `validateTags` (which `cacheTag()`, `unstable_cache()`, and `fetch` tags all funnel through), `getImplicitTags` for path-derived tags, and `revalidatePath` / `revalidateTag` / `updateTag` for invalidation inputs. The encoder matches runs of out-of-class code units so surrogate pairs reach `encodeURIComponent` intact, and it is idempotent on already-encoded `%xx` sequences, so callers can pass either the raw or the encoded form interchangeably. PR #93139 already encodes path-derived tags at construction, but it misses every user-supplied tag entry point and uses a `decodeURIComponent` round-trip that silently mangles literal `%xx` characters in tag values. PR #93167 encodes only at the `setHeader` sites, which leaves storage and invalidation diverging and requires every new write site to remember the encoding step. The canonical-form-at-the-boundary approach taken here covers all entry points and keeps storage, comparison, and the wire in sync. fixes #93142 closes #93139 closes #93167 Co-authored-by: Swarnava Sengupta <swarnava.sengupta@vercel.com> Co-authored-by: Or Nakash <ornakash@gmail.com>
unstubbable
added a commit
that referenced
this pull request
May 18, 2026
When a cache tag contains a non-ASCII character (Hebrew, CJK, emoji, …) it gets written into the internal `x-next-cache-tags` HTTP header on ISR responses. Node's `validateHeaderValue` rejects any byte outside `\t\x20-\x7e`, so the response crashes with `ERR_INVALID_CHAR`. On Vercel deploys stale-if-error masks the 500 from clients, but revalidation itself keeps failing and the cache stops refreshing for affected routes. This change introduces a single `encodeCacheTag` helper and applies it at every public boundary — `validateTags` (which `cacheTag()`, `unstable_cache()`, and `fetch` tags all funnel through), `getImplicitTags` for path-derived tags, and `revalidatePath` / `revalidateTag` / `updateTag` for invalidation inputs. The encoder matches runs of out-of-class code units so surrogate pairs reach `encodeURIComponent` intact, and it is idempotent on already-encoded `%xx` sequences, so callers can pass either the raw or the encoded form interchangeably. PR #93139 already encodes path-derived tags at construction, but it misses every user-supplied tag entry point and uses a `decodeURIComponent` round-trip that silently mangles literal `%xx` characters in tag values. PR #93167 encodes only at the `setHeader` sites, which leaves storage and invalidation diverging and requires every new write site to remember the encoding step. The canonical-form-at-the-boundary approach taken here covers all entry points and keeps storage, comparison, and the wire in sync. fixes #93142 closes #93139 closes #93167 Co-authored-by: Swarnava Sengupta <swarnava.sengupta@vercel.com> Co-authored-by: Or Nakash <ornakash@gmail.com>
unstubbable
added a commit
that referenced
this pull request
May 19, 2026
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
When a cache tag contains a non-ASCII character (Hebrew, CJK, emoji, …) it gets written into the internal
x-next-cache-tagsHTTP header on ISR responses. Node'svalidateHeaderValuerejects any byte outside\t\x20-\x7e, so the response crashes withERR_INVALID_CHAR. On Vercel deploys stale-if-error masks the 500 from clients, but revalidation itself keeps failing and the cache stops refreshing for affected routes.This change introduces a single
encodeCacheTaghelper and applies it at every public boundary —validateTags(whichcacheTag(),unstable_cache(), andfetchtags all funnel through),getImplicitTagsfor path-derived tags, andrevalidatePath/revalidateTag/updateTagfor invalidation inputs. The encoder matches runs of out-of-class code units so surrogate pairs reachencodeURIComponentintact, and it is idempotent on already-encoded%xxsequences, so callers can pass either the raw or the encoded form interchangeably.PR #93139 already encodes path-derived tags at construction, but it misses every user-supplied tag entry point and uses a
decodeURIComponentround-trip that silently mangles literal%xxcharacters in tag values. PR #93167 encodes only at thesetHeadersites, which leaves storage and invalidation diverging and requires every new write site to remember the encoding step. The canonical-form-at-the-boundary approach taken here covers all entry points and keeps storage, comparison, and the wire in sync.fixes #93142
closes #93139
closes #93167
Co-authored-by: @swarnava
Co-authored-by: @ornakash