feat(web): address server function calls by path by frenzzy · Pull Request #3076 · solidjs/solid

frenzzy · 2026-08-27T05:05:21Z

Implements the split settled in #3072: the id moves to the path, the arguments stay in the query.

The first revision of this PR put arguments in the path too. That's withdrawn — two of the objections landed. Bound arguments ride urls on POSTs as well, where path placement buys nothing and turns the url into a hybrid of path-baked arguments plus a body; and query-scrubbing is ubiquitous in log tooling while path-scrubbing isn't, which matters when arguments carry emails and search terms. The remaining case for path-baked arguments was resilience against a zone configured to ignore query strings, and with the id in the path that failure is already bounded to one function's arguments rather than serving another function's response — a config bug to document, not a reason to contort the scheme.

What changes

<endpoint>/<id> for GET and POST alike.fn.url is /_server/<id>; arguments stay in ?args=, unchanged in encoding.
X-Server-Function-Id is gone — from the wire and from the package's exports. With the id nowhere but the url, a cache in front of the app cannot be made to store one function's response under another's key, which closesX-Server-Function-Id overrides the id in the URL, making it an unkeyed input to a cacheable response #3070 by construction rather than by rule. X-Server-Function-Instance still marks a scripted call.
serverFunctionUrl(id, boundArgs?) / parseServerFunctionUrl(url) on both entries, resolved against the configured endpoint. This is your "export a URL builder" note: solid-router composes form-action urls with bound arguments for the no-JS path, and it currently recovers the id with new URL(url, mockBase).searchParams.get("id") (src/data/action.ts) — that line becomes parseServerFunctionUrl(url). It's the only coupling: the router passes the url on to createServerReference(id, undefined, url), which still targets a base verbatim.
URL length falls back to POST. A GET call whose encoded url would exceed 2000 characters dispatches over POST instead — declaring GET grants the read methods without revoking the default transport, so the call still runs, it just isn't cacheable. A cache miss, not a 414 from whichever proxy draws the line first.
method="get" forms work (second commit, droppable on its own). A GET submit replaces the action url's query with the form's fields — only an address in the path survives one — and those fields now reach the function as a lone URLSearchParams, the read-side mirror of a no-JS form post decoding to a lone FormData.

On your other two notes: argument encoding is left exactly as it was, since positional arguments are ordered by construction and need no canonicalization layer (the one residue is object key order inside an argument, which is a JSON property, not an addressing one); and deploy skew is treated as a docs matter, with no machinery added.

Shape of the change

188 lines of runtime across the three files, most of it comments. Both halves build and parse the address through one pair of functions in shared.ts (serverFunctionAddress / parseServerFunctionAddress), which also retires a standing hazard: endpoint had to be configured identically on client and server by hand, and there was no shared definition of what it produced. live inherits the address through fn.url; frameAddress is untouched (a logical region address, not a url). A path carrying more than the one segment the address gives meaning to answers 404 rather than matching on its prefix.

Which reading a url gets is decided by the url alone

Worth calling out because the first cut of the second commit got it wrong: the choice between "this query is an argument encoding" and "this query is a form's fields" keys on the url only, never on the instance header. Otherwise a GET-declared function with cache-control: public answers the same url with two different bodies depending on a header no cache keys on and no Vary names — a cross-site prefetch could force one variant into the entry every scripted client then reads, which is the axis #3070 is about. args stays reserved on the query, and a value under it that is not an argument array answers 400 for every caller of that url rather than spreading into whatever the encoding produced.

Verification

pnpm test at the root: 32/32 turbo tasks green, rebased on next @ 258c76a. @solidjs/web across its three configs: 609 + 322 + 146. The addressing spec is 20 cases against the built bundles: the GET and POST addresses, the POST fallback and its url-length boundary, that the fallback stays a read (no single-flight collection), bound arguments with a FormData body over the real no-JS post, the refusal to render bound arguments JSON cannot carry, the same-url-same-answer invariant, args degenerate encodings answering 400, the id header and ?id= no longer addressing anything, the query reading on GET and HEAD, building and parsing action urls from both entries, a mount path with a trailing slash, a request outside the mount, an id with characters the path must encode, and the 404s for a bare, trailing-slash, or over-long path. Existing specs that hand-built the old wire shape are updated — including server-functions-http-hygiene.spec.tsx from 258c76a — and RFC 10 is updated where it describes the format.

Two red checks (job, Run benchmarks) fail the same way on next itself at 258c76a — Failed: @solidjs/element#test, a package this branch doesn't touch.

Known limits, stated rather than hidden

A method="get" submit reaches the function, but what the browser then renders is the raw serialized result: handleNoJS's redirect convention is a form-post one (isFormPost is POST-only), so a read that wants to render something should return a Response. Deliberate — redirecting a read would lose the thing the read produced.
A URLSearchParams argument has no encoding on the GET query path (isJSONSafe rejects it), so the shape the form convention produces cannot be sent by a scripted GET. The symmetric fix — a lone URLSearchParams argument becoming the query itself, which would make the scripted and unscripted urls identical — is a natural follow-up, left out to keep this a pure addressing change.
parseServerFunctionUrl reads the path only; a caller that cares whether a url is its own origin checks that itself.

Relationship to `258c76a`

The method allowlist and cache hygiene need nothing from this change and vice versa; the rebase only touched that commit's new spec request builders. One interaction is deliberate: HEAD is a read that mirrors GET, so an unscripted HEAD gets the same lone URLSearchParams a GET would — a HEAD to a form url describes the GET response, arguments included.

changeset-bot · 2026-08-27T05:05:26Z

🦋 Changeset detected

Latest commit: 3988224

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
test-integration	Patch
solid-js	Patch
@solidjs/compiler	Patch
@solidjs/universal	Patch
@solidjs/signals	Patch
@solidjs/diagnostics	Patch

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

The function id travelled in `X-Server-Function-Id`, with `?id=` as the fallback for requests the client runtime did not make. Both are gone; it moves into the path — `<endpoint>/<id>` — which is what per-function policy keys on: edge rules, cache policies by path pattern, rate limits, log aggregation, `http.route` labels in traces. It also leaves exactly one place in the request carrying the id, which closessolidjs#3070 by construction: with no header to override the url, a cache in front of the app cannot be made to store one function's response under another's key. POST addresses move too — no caching reason, the same legibility — and that is what lets the header disappear entirely instead of surviving as the POST addressing channel. `endpoint` gates dispatch on both halves as a result: a request whose path does not start with it is not a call. Arguments stay in the query, where caches key on them, log tooling scrubs them, path normalization leaves them alone, and bound arguments already ride for form posts. A value under `args` that is not an argument array answers 400 rather than spreading into whatever the encoding happened to produce. A GET call whose url would exceed 2000 characters — measured on the wire, origin included — dispatches over POST instead, marked as a read so it asks for no single-flight collection: a cache miss rather than a 414 from whichever proxy in the chain draws the line first. `serverFunctionUrl(id, boundArgs?)` and `parseServerFunctionUrl(url)` export the two halves of the scheme from both entries, so integrations composing action urls build them through the runtime rather than hand-rolling the shape.

A `method="get"` form submit replaces the action url's query with the form's fields — which is why only an address in the path survives one — so a read whose query is not an argument encoding is carrying a form, not arguments. That query now reaches the function as a lone `URLSearchParams`, the read-side mirror of a no-JS form post decoding to a lone `FormData`: <form method="get" action={search.url}> <input name="q" /> </form>  Which reading applies is decided by the url alone, never by a header: a cache keys on the url, so the same url has to mean the same call whether or not the client runtime made it. HEAD reads it the same way as the GET it mirrors. What a GET submit renders is the function's to shape — the no-JS redirect convention is a form-post one, and a read has something to say.

codspeed-hq · 2026-08-27T07:28:05Z

Merging this PR will regress 1 benchmark

⚠️

Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.
Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
❌ 1 regressed benchmark
✅ 127 untouched benchmarks
⏩ 131 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	`BASE`	`HEAD`	Efficiency
❌	`merge`	70.7 µs	138.2 µs	-48.85%
⚡	`merge`	173.7 µs	73.7 µs	×2.4
⚡	`merge`	279.9 µs	187.8 µs	+49.04%
⚡	`merge`	357.3 µs	267.5 µs	+33.55%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing frenzzy:sf-path-addressing (3988224) with next (e8c8947)}

131 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

rc.4 publishes the path-addressed server function calls this branch routes (solidjs/solid#3076): the client computes `<endpoint>/<id>` and the published server handler resolves the id from the path alone — the X-Server-Function-Id header and `?id=` forms are gone from the runtime, not just retired client-side. The workspace catalog moves to ^2.0.0-rc.4 (minimumReleaseAgeExclude extended per the existing pattern), and the start-ssr suite's synthetic dispatches switch from `?id=` to the path form, since the published handler no longer answers the legacy shape. The plugin's own transitional fallbacks stay: they serve runtimes older than the addressing change, which the peer range still admits. Full gate green against published rc.4 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

The dist-types check failed because the lockfile still resolved @solidjs/web 2.0.0-rc.3, which predates parseServerFunctionUrl — the runtime half of the addressing scheme this branch adopts. The peer and dev floors now say what the code means: ^2.0.0-rc.4. The vite plugin moves to 3.0.0-next.35 (the plugin half of solidjs/solid#3076), which requires vite 8, which requires vitest 4 — test-toolchain-only, but vitest 4 constructs `new FormData()` through the mock's implementation, so the arrow-function stubs become real functions (arrows aren't constructable), and one Mock type annotation gains its signature. Co-authored-by: Cursor <cursoragent@cursor.com>

frenzzy · 2026-08-27T05:05:21Z

Implements the split settled in #3072: the id moves to the path, the arguments stay in the query.

The first revision of this PR put arguments in the path too. That's withdrawn — two of the objections landed. Bound arguments ride urls on POSTs as well, where path placement buys nothing and turns the url into a hybrid of path-baked arguments plus a body; and query-scrubbing is ubiquitous in log tooling while path-scrubbing isn't, which matters when arguments carry emails and search terms. The remaining case for path-baked arguments was resilience against a zone configured to ignore query strings, and with the id in the path that failure is already bounded to one function's arguments rather than serving another function's response — a config bug to document, not a reason to contort the scheme.

What changes

<endpoint>/<id> for GET and POST alike.fn.url is /_server/<id>; arguments stay in ?args=, unchanged in encoding.
X-Server-Function-Id is gone — from the wire and from the package's exports. With the id nowhere but the url, a cache in front of the app cannot be made to store one function's response under another's key, which closesX-Server-Function-Id overrides the id in the URL, making it an unkeyed input to a cacheable response #3070 by construction rather than by rule. X-Server-Function-Instance still marks a scripted call.
serverFunctionUrl(id, boundArgs?) / parseServerFunctionUrl(url) on both entries, resolved against the configured endpoint. This is your "export a URL builder" note: solid-router composes form-action urls with bound arguments for the no-JS path, and it currently recovers the id with new URL(url, mockBase).searchParams.get("id") (src/data/action.ts) — that line becomes parseServerFunctionUrl(url). It's the only coupling: the router passes the url on to createServerReference(id, undefined, url), which still targets a base verbatim.
URL length falls back to POST. A GET call whose encoded url would exceed 2000 characters dispatches over POST instead — declaring GET grants the read methods without revoking the default transport, so the call still runs, it just isn't cacheable. A cache miss, not a 414 from whichever proxy draws the line first.
method="get" forms work (second commit, droppable on its own). A GET submit replaces the action url's query with the form's fields — only an address in the path survives one — and those fields now reach the function as a lone URLSearchParams, the read-side mirror of a no-JS form post decoding to a lone FormData.

On your other two notes: argument encoding is left exactly as it was, since positional arguments are ordered by construction and need no canonicalization layer (the one residue is object key order inside an argument, which is a JSON property, not an addressing one); and deploy skew is treated as a docs matter, with no machinery added.

Shape of the change

188 lines of runtime across the three files, most of it comments. Both halves build and parse the address through one pair of functions in shared.ts (serverFunctionAddress / parseServerFunctionAddress), which also retires a standing hazard: endpoint had to be configured identically on client and server by hand, and there was no shared definition of what it produced. live inherits the address through fn.url; frameAddress is untouched (a logical region address, not a url). A path carrying more than the one segment the address gives meaning to answers 404 rather than matching on its prefix.

Which reading a url gets is decided by the url alone

Worth calling out because the first cut of the second commit got it wrong: the choice between "this query is an argument encoding" and "this query is a form's fields" keys on the url only, never on the instance header. Otherwise a GET-declared function with cache-control: public answers the same url with two different bodies depending on a header no cache keys on and no Vary names — a cross-site prefetch could force one variant into the entry every scripted client then reads, which is the axis #3070 is about. args stays reserved on the query, and a value under it that is not an argument array answers 400 for every caller of that url rather than spreading into whatever the encoding produced.

Verification

pnpm test at the root: 32/32 turbo tasks green, rebased on next @ 258c76a. @solidjs/web across its three configs: 609 + 322 + 146. The addressing spec is 20 cases against the built bundles: the GET and POST addresses, the POST fallback and its url-length boundary, that the fallback stays a read (no single-flight collection), bound arguments with a FormData body over the real no-JS post, the refusal to render bound arguments JSON cannot carry, the same-url-same-answer invariant, args degenerate encodings answering 400, the id header and ?id= no longer addressing anything, the query reading on GET and HEAD, building and parsing action urls from both entries, a mount path with a trailing slash, a request outside the mount, an id with characters the path must encode, and the 404s for a bare, trailing-slash, or over-long path. Existing specs that hand-built the old wire shape are updated — including server-functions-http-hygiene.spec.tsx from 258c76a — and RFC 10 is updated where it describes the format.

Two red checks (job, Run benchmarks) fail the same way on next itself at 258c76a — Failed: @solidjs/element#test, a package this branch doesn't touch.

Known limits, stated rather than hidden

A method="get" submit reaches the function, but what the browser then renders is the raw serialized result: handleNoJS's redirect convention is a form-post one (isFormPost is POST-only), so a read that wants to render something should return a Response. Deliberate — redirecting a read would lose the thing the read produced.
A URLSearchParams argument has no encoding on the GET query path (isJSONSafe rejects it), so the shape the form convention produces cannot be sent by a scripted GET. The symmetric fix — a lone URLSearchParams argument becoming the query itself, which would make the scripted and unscripted urls identical — is a natural follow-up, left out to keep this a pure addressing change.
parseServerFunctionUrl reads the path only; a caller that cares whether a url is its own origin checks that itself.

Relationship to `258c76a`

The method allowlist and cache hygiene need nothing from this change and vice versa; the rebase only touched that commit's new spec request builders. One interaction is deliberate: HEAD is a read that mirrors GET, so an unscripted HEAD gets the same lone URLSearchParams a GET would — a HEAD to a form url describes the GET response, arguments included.

changeset-bot · 2026-08-27T05:05:26Z

🦋 Changeset detected

Latest commit: 3988224

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
test-integration	Patch
solid-js	Patch
@solidjs/compiler	Patch
@solidjs/universal	Patch
@solidjs/signals	Patch
@solidjs/diagnostics	Patch

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

The function id travelled in `X-Server-Function-Id`, with `?id=` as the fallback for requests the client runtime did not make. Both are gone; it moves into the path — `<endpoint>/<id>` — which is what per-function policy keys on: edge rules, cache policies by path pattern, rate limits, log aggregation, `http.route` labels in traces. It also leaves exactly one place in the request carrying the id, which closessolidjs#3070 by construction: with no header to override the url, a cache in front of the app cannot be made to store one function's response under another's key. POST addresses move too — no caching reason, the same legibility — and that is what lets the header disappear entirely instead of surviving as the POST addressing channel. `endpoint` gates dispatch on both halves as a result: a request whose path does not start with it is not a call. Arguments stay in the query, where caches key on them, log tooling scrubs them, path normalization leaves them alone, and bound arguments already ride for form posts. A value under `args` that is not an argument array answers 400 rather than spreading into whatever the encoding happened to produce. A GET call whose url would exceed 2000 characters — measured on the wire, origin included — dispatches over POST instead, marked as a read so it asks for no single-flight collection: a cache miss rather than a 414 from whichever proxy in the chain draws the line first. `serverFunctionUrl(id, boundArgs?)` and `parseServerFunctionUrl(url)` export the two halves of the scheme from both entries, so integrations composing action urls build them through the runtime rather than hand-rolling the shape.

A `method="get"` form submit replaces the action url's query with the form's fields — which is why only an address in the path survives one — so a read whose query is not an argument encoding is carrying a form, not arguments. That query now reaches the function as a lone `URLSearchParams`, the read-side mirror of a no-JS form post decoding to a lone `FormData`: <form method="get" action={search.url}> <input name="q" /> </form>  Which reading applies is decided by the url alone, never by a header: a cache keys on the url, so the same url has to mean the same call whether or not the client runtime made it. HEAD reads it the same way as the GET it mirrors. What a GET submit renders is the function's to shape — the no-JS redirect convention is a form-post one, and a read has something to say.

codspeed-hq · 2026-08-27T07:28:05Z

Merging this PR will regress 1 benchmark

⚠️

Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.
Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
❌ 1 regressed benchmark
✅ 127 untouched benchmarks
⏩ 131 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	`BASE`	`HEAD`	Efficiency
❌	`merge`	70.7 µs	138.2 µs	-48.85%
⚡	`merge`	173.7 µs	73.7 µs	×2.4
⚡	`merge`	279.9 µs	187.8 µs	+49.04%
⚡	`merge`	357.3 µs	267.5 µs	+33.55%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing frenzzy:sf-path-addressing (3988224) with next (e8c8947)}

131 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

rc.4 publishes the path-addressed server function calls this branch routes (solidjs/solid#3076): the client computes `<endpoint>/<id>` and the published server handler resolves the id from the path alone — the X-Server-Function-Id header and `?id=` forms are gone from the runtime, not just retired client-side. The workspace catalog moves to ^2.0.0-rc.4 (minimumReleaseAgeExclude extended per the existing pattern), and the start-ssr suite's synthetic dispatches switch from `?id=` to the path form, since the published handler no longer answers the legacy shape. The plugin's own transitional fallbacks stay: they serve runtimes older than the addressing change, which the peer range still admits. Full gate green against published rc.4 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

The dist-types check failed because the lockfile still resolved @solidjs/web 2.0.0-rc.3, which predates parseServerFunctionUrl — the runtime half of the addressing scheme this branch adopts. The peer and dev floors now say what the code means: ^2.0.0-rc.4. The vite plugin moves to 3.0.0-next.35 (the plugin half of solidjs/solid#3076), which requires vite 8, which requires vitest 4 — test-toolchain-only, but vitest 4 constructs `new FormData()` through the mock's implementation, so the arrow-function stubs become real functions (arrows aren't constructable), and one Mock type annotation gains its signature. Co-authored-by: Cursor <cursoragent@cursor.com>

frenzzy · 2026-08-27T05:05:21Z

Implements the split settled in #3072: the id moves to the path, the arguments stay in the query.

The first revision of this PR put arguments in the path too. That's withdrawn — two of the objections landed. Bound arguments ride urls on POSTs as well, where path placement buys nothing and turns the url into a hybrid of path-baked arguments plus a body; and query-scrubbing is ubiquitous in log tooling while path-scrubbing isn't, which matters when arguments carry emails and search terms. The remaining case for path-baked arguments was resilience against a zone configured to ignore query strings, and with the id in the path that failure is already bounded to one function's arguments rather than serving another function's response — a config bug to document, not a reason to contort the scheme.

What changes

<endpoint>/<id> for GET and POST alike.fn.url is /_server/<id>; arguments stay in ?args=, unchanged in encoding.
X-Server-Function-Id is gone — from the wire and from the package's exports. With the id nowhere but the url, a cache in front of the app cannot be made to store one function's response under another's key, which closesX-Server-Function-Id overrides the id in the URL, making it an unkeyed input to a cacheable response #3070 by construction rather than by rule. X-Server-Function-Instance still marks a scripted call.
serverFunctionUrl(id, boundArgs?) / parseServerFunctionUrl(url) on both entries, resolved against the configured endpoint. This is your "export a URL builder" note: solid-router composes form-action urls with bound arguments for the no-JS path, and it currently recovers the id with new URL(url, mockBase).searchParams.get("id") (src/data/action.ts) — that line becomes parseServerFunctionUrl(url). It's the only coupling: the router passes the url on to createServerReference(id, undefined, url), which still targets a base verbatim.
URL length falls back to POST. A GET call whose encoded url would exceed 2000 characters dispatches over POST instead — declaring GET grants the read methods without revoking the default transport, so the call still runs, it just isn't cacheable. A cache miss, not a 414 from whichever proxy draws the line first.
method="get" forms work (second commit, droppable on its own). A GET submit replaces the action url's query with the form's fields — only an address in the path survives one — and those fields now reach the function as a lone URLSearchParams, the read-side mirror of a no-JS form post decoding to a lone FormData.

On your other two notes: argument encoding is left exactly as it was, since positional arguments are ordered by construction and need no canonicalization layer (the one residue is object key order inside an argument, which is a JSON property, not an addressing one); and deploy skew is treated as a docs matter, with no machinery added.

Shape of the change

188 lines of runtime across the three files, most of it comments. Both halves build and parse the address through one pair of functions in shared.ts (serverFunctionAddress / parseServerFunctionAddress), which also retires a standing hazard: endpoint had to be configured identically on client and server by hand, and there was no shared definition of what it produced. live inherits the address through fn.url; frameAddress is untouched (a logical region address, not a url). A path carrying more than the one segment the address gives meaning to answers 404 rather than matching on its prefix.

Which reading a url gets is decided by the url alone

Worth calling out because the first cut of the second commit got it wrong: the choice between "this query is an argument encoding" and "this query is a form's fields" keys on the url only, never on the instance header. Otherwise a GET-declared function with cache-control: public answers the same url with two different bodies depending on a header no cache keys on and no Vary names — a cross-site prefetch could force one variant into the entry every scripted client then reads, which is the axis #3070 is about. args stays reserved on the query, and a value under it that is not an argument array answers 400 for every caller of that url rather than spreading into whatever the encoding produced.

Verification

pnpm test at the root: 32/32 turbo tasks green, rebased on next @ 258c76a. @solidjs/web across its three configs: 609 + 322 + 146. The addressing spec is 20 cases against the built bundles: the GET and POST addresses, the POST fallback and its url-length boundary, that the fallback stays a read (no single-flight collection), bound arguments with a FormData body over the real no-JS post, the refusal to render bound arguments JSON cannot carry, the same-url-same-answer invariant, args degenerate encodings answering 400, the id header and ?id= no longer addressing anything, the query reading on GET and HEAD, building and parsing action urls from both entries, a mount path with a trailing slash, a request outside the mount, an id with characters the path must encode, and the 404s for a bare, trailing-slash, or over-long path. Existing specs that hand-built the old wire shape are updated — including server-functions-http-hygiene.spec.tsx from 258c76a — and RFC 10 is updated where it describes the format.

Two red checks (job, Run benchmarks) fail the same way on next itself at 258c76a — Failed: @solidjs/element#test, a package this branch doesn't touch.

Known limits, stated rather than hidden

A method="get" submit reaches the function, but what the browser then renders is the raw serialized result: handleNoJS's redirect convention is a form-post one (isFormPost is POST-only), so a read that wants to render something should return a Response. Deliberate — redirecting a read would lose the thing the read produced.
A URLSearchParams argument has no encoding on the GET query path (isJSONSafe rejects it), so the shape the form convention produces cannot be sent by a scripted GET. The symmetric fix — a lone URLSearchParams argument becoming the query itself, which would make the scripted and unscripted urls identical — is a natural follow-up, left out to keep this a pure addressing change.
parseServerFunctionUrl reads the path only; a caller that cares whether a url is its own origin checks that itself.

Relationship to `258c76a`

The method allowlist and cache hygiene need nothing from this change and vice versa; the rebase only touched that commit's new spec request builders. One interaction is deliberate: HEAD is a read that mirrors GET, so an unscripted HEAD gets the same lone URLSearchParams a GET would — a HEAD to a form url describes the GET response, arguments included.

changeset-bot · 2026-08-27T05:05:26Z

🦋 Changeset detected

Latest commit: 3988224

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
test-integration	Patch
solid-js	Patch
@solidjs/compiler	Patch
@solidjs/universal	Patch
@solidjs/signals	Patch
@solidjs/diagnostics	Patch

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

The function id travelled in `X-Server-Function-Id`, with `?id=` as the fallback for requests the client runtime did not make. Both are gone; it moves into the path — `<endpoint>/<id>` — which is what per-function policy keys on: edge rules, cache policies by path pattern, rate limits, log aggregation, `http.route` labels in traces. It also leaves exactly one place in the request carrying the id, which closessolidjs#3070 by construction: with no header to override the url, a cache in front of the app cannot be made to store one function's response under another's key. POST addresses move too — no caching reason, the same legibility — and that is what lets the header disappear entirely instead of surviving as the POST addressing channel. `endpoint` gates dispatch on both halves as a result: a request whose path does not start with it is not a call. Arguments stay in the query, where caches key on them, log tooling scrubs them, path normalization leaves them alone, and bound arguments already ride for form posts. A value under `args` that is not an argument array answers 400 rather than spreading into whatever the encoding happened to produce. A GET call whose url would exceed 2000 characters — measured on the wire, origin included — dispatches over POST instead, marked as a read so it asks for no single-flight collection: a cache miss rather than a 414 from whichever proxy in the chain draws the line first. `serverFunctionUrl(id, boundArgs?)` and `parseServerFunctionUrl(url)` export the two halves of the scheme from both entries, so integrations composing action urls build them through the runtime rather than hand-rolling the shape.

A `method="get"` form submit replaces the action url's query with the form's fields — which is why only an address in the path survives one — so a read whose query is not an argument encoding is carrying a form, not arguments. That query now reaches the function as a lone `URLSearchParams`, the read-side mirror of a no-JS form post decoding to a lone `FormData`: <form method="get" action={search.url}> <input name="q" /> </form>  Which reading applies is decided by the url alone, never by a header: a cache keys on the url, so the same url has to mean the same call whether or not the client runtime made it. HEAD reads it the same way as the GET it mirrors. What a GET submit renders is the function's to shape — the no-JS redirect convention is a form-post one, and a read has something to say.

codspeed-hq · 2026-08-27T07:28:05Z

Merging this PR will regress 1 benchmark

⚠️

Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.
Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
❌ 1 regressed benchmark
✅ 127 untouched benchmarks
⏩ 131 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	`BASE`	`HEAD`	Efficiency
❌	`merge`	70.7 µs	138.2 µs	-48.85%
⚡	`merge`	173.7 µs	73.7 µs	×2.4
⚡	`merge`	279.9 µs	187.8 µs	+49.04%
⚡	`merge`	357.3 µs	267.5 µs	+33.55%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing frenzzy:sf-path-addressing (3988224) with next (e8c8947)}

131 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

rc.4 publishes the path-addressed server function calls this branch routes (solidjs/solid#3076): the client computes `<endpoint>/<id>` and the published server handler resolves the id from the path alone — the X-Server-Function-Id header and `?id=` forms are gone from the runtime, not just retired client-side. The workspace catalog moves to ^2.0.0-rc.4 (minimumReleaseAgeExclude extended per the existing pattern), and the start-ssr suite's synthetic dispatches switch from `?id=` to the path form, since the published handler no longer answers the legacy shape. The plugin's own transitional fallbacks stay: they serve runtimes older than the addressing change, which the peer range still admits. Full gate green against published rc.4 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

The dist-types check failed because the lockfile still resolved @solidjs/web 2.0.0-rc.3, which predates parseServerFunctionUrl — the runtime half of the addressing scheme this branch adopts. The peer and dev floors now say what the code means: ^2.0.0-rc.4. The vite plugin moves to 3.0.0-next.35 (the plugin half of solidjs/solid#3076), which requires vite 8, which requires vitest 4 — test-toolchain-only, but vitest 4 constructs `new FormData()` through the mock's implementation, so the arrow-function stubs become real functions (arrows aren't constructable), and one Mock type annotation gains its signature. Co-authored-by: Cursor <cursoragent@cursor.com>

frenzzy · 2026-08-27T05:05:21Z

Implements the split settled in #3072: the id moves to the path, the arguments stay in the query.

The first revision of this PR put arguments in the path too. That's withdrawn — two of the objections landed. Bound arguments ride urls on POSTs as well, where path placement buys nothing and turns the url into a hybrid of path-baked arguments plus a body; and query-scrubbing is ubiquitous in log tooling while path-scrubbing isn't, which matters when arguments carry emails and search terms. The remaining case for path-baked arguments was resilience against a zone configured to ignore query strings, and with the id in the path that failure is already bounded to one function's arguments rather than serving another function's response — a config bug to document, not a reason to contort the scheme.

What changes

<endpoint>/<id> for GET and POST alike.fn.url is /_server/<id>; arguments stay in ?args=, unchanged in encoding.
X-Server-Function-Id is gone — from the wire and from the package's exports. With the id nowhere but the url, a cache in front of the app cannot be made to store one function's response under another's key, which closesX-Server-Function-Id overrides the id in the URL, making it an unkeyed input to a cacheable response #3070 by construction rather than by rule. X-Server-Function-Instance still marks a scripted call.
serverFunctionUrl(id, boundArgs?) / parseServerFunctionUrl(url) on both entries, resolved against the configured endpoint. This is your "export a URL builder" note: solid-router composes form-action urls with bound arguments for the no-JS path, and it currently recovers the id with new URL(url, mockBase).searchParams.get("id") (src/data/action.ts) — that line becomes parseServerFunctionUrl(url). It's the only coupling: the router passes the url on to createServerReference(id, undefined, url), which still targets a base verbatim.
URL length falls back to POST. A GET call whose encoded url would exceed 2000 characters dispatches over POST instead — declaring GET grants the read methods without revoking the default transport, so the call still runs, it just isn't cacheable. A cache miss, not a 414 from whichever proxy draws the line first.
method="get" forms work (second commit, droppable on its own). A GET submit replaces the action url's query with the form's fields — only an address in the path survives one — and those fields now reach the function as a lone URLSearchParams, the read-side mirror of a no-JS form post decoding to a lone FormData.

On your other two notes: argument encoding is left exactly as it was, since positional arguments are ordered by construction and need no canonicalization layer (the one residue is object key order inside an argument, which is a JSON property, not an addressing one); and deploy skew is treated as a docs matter, with no machinery added.

Shape of the change

188 lines of runtime across the three files, most of it comments. Both halves build and parse the address through one pair of functions in shared.ts (serverFunctionAddress / parseServerFunctionAddress), which also retires a standing hazard: endpoint had to be configured identically on client and server by hand, and there was no shared definition of what it produced. live inherits the address through fn.url; frameAddress is untouched (a logical region address, not a url). A path carrying more than the one segment the address gives meaning to answers 404 rather than matching on its prefix.

Which reading a url gets is decided by the url alone

Worth calling out because the first cut of the second commit got it wrong: the choice between "this query is an argument encoding" and "this query is a form's fields" keys on the url only, never on the instance header. Otherwise a GET-declared function with cache-control: public answers the same url with two different bodies depending on a header no cache keys on and no Vary names — a cross-site prefetch could force one variant into the entry every scripted client then reads, which is the axis #3070 is about. args stays reserved on the query, and a value under it that is not an argument array answers 400 for every caller of that url rather than spreading into whatever the encoding produced.

Verification

pnpm test at the root: 32/32 turbo tasks green, rebased on next @ 258c76a. @solidjs/web across its three configs: 609 + 322 + 146. The addressing spec is 20 cases against the built bundles: the GET and POST addresses, the POST fallback and its url-length boundary, that the fallback stays a read (no single-flight collection), bound arguments with a FormData body over the real no-JS post, the refusal to render bound arguments JSON cannot carry, the same-url-same-answer invariant, args degenerate encodings answering 400, the id header and ?id= no longer addressing anything, the query reading on GET and HEAD, building and parsing action urls from both entries, a mount path with a trailing slash, a request outside the mount, an id with characters the path must encode, and the 404s for a bare, trailing-slash, or over-long path. Existing specs that hand-built the old wire shape are updated — including server-functions-http-hygiene.spec.tsx from 258c76a — and RFC 10 is updated where it describes the format.

Two red checks (job, Run benchmarks) fail the same way on next itself at 258c76a — Failed: @solidjs/element#test, a package this branch doesn't touch.

Known limits, stated rather than hidden

A method="get" submit reaches the function, but what the browser then renders is the raw serialized result: handleNoJS's redirect convention is a form-post one (isFormPost is POST-only), so a read that wants to render something should return a Response. Deliberate — redirecting a read would lose the thing the read produced.
A URLSearchParams argument has no encoding on the GET query path (isJSONSafe rejects it), so the shape the form convention produces cannot be sent by a scripted GET. The symmetric fix — a lone URLSearchParams argument becoming the query itself, which would make the scripted and unscripted urls identical — is a natural follow-up, left out to keep this a pure addressing change.
parseServerFunctionUrl reads the path only; a caller that cares whether a url is its own origin checks that itself.

Relationship to `258c76a`

The method allowlist and cache hygiene need nothing from this change and vice versa; the rebase only touched that commit's new spec request builders. One interaction is deliberate: HEAD is a read that mirrors GET, so an unscripted HEAD gets the same lone URLSearchParams a GET would — a HEAD to a form url describes the GET response, arguments included.

changeset-bot · 2026-08-27T05:05:26Z

🦋 Changeset detected

Latest commit: 3988224

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
test-integration	Patch
solid-js	Patch
@solidjs/compiler	Patch
@solidjs/universal	Patch
@solidjs/signals	Patch
@solidjs/diagnostics	Patch

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

The function id travelled in `X-Server-Function-Id`, with `?id=` as the fallback for requests the client runtime did not make. Both are gone; it moves into the path — `<endpoint>/<id>` — which is what per-function policy keys on: edge rules, cache policies by path pattern, rate limits, log aggregation, `http.route` labels in traces. It also leaves exactly one place in the request carrying the id, which closessolidjs#3070 by construction: with no header to override the url, a cache in front of the app cannot be made to store one function's response under another's key. POST addresses move too — no caching reason, the same legibility — and that is what lets the header disappear entirely instead of surviving as the POST addressing channel. `endpoint` gates dispatch on both halves as a result: a request whose path does not start with it is not a call. Arguments stay in the query, where caches key on them, log tooling scrubs them, path normalization leaves them alone, and bound arguments already ride for form posts. A value under `args` that is not an argument array answers 400 rather than spreading into whatever the encoding happened to produce. A GET call whose url would exceed 2000 characters — measured on the wire, origin included — dispatches over POST instead, marked as a read so it asks for no single-flight collection: a cache miss rather than a 414 from whichever proxy in the chain draws the line first. `serverFunctionUrl(id, boundArgs?)` and `parseServerFunctionUrl(url)` export the two halves of the scheme from both entries, so integrations composing action urls build them through the runtime rather than hand-rolling the shape.

A `method="get"` form submit replaces the action url's query with the form's fields — which is why only an address in the path survives one — so a read whose query is not an argument encoding is carrying a form, not arguments. That query now reaches the function as a lone `URLSearchParams`, the read-side mirror of a no-JS form post decoding to a lone `FormData`: <form method="get" action={search.url}> <input name="q" /> </form>  Which reading applies is decided by the url alone, never by a header: a cache keys on the url, so the same url has to mean the same call whether or not the client runtime made it. HEAD reads it the same way as the GET it mirrors. What a GET submit renders is the function's to shape — the no-JS redirect convention is a form-post one, and a read has something to say.

codspeed-hq · 2026-08-27T07:28:05Z

Merging this PR will regress 1 benchmark

⚠️

Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.
Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
❌ 1 regressed benchmark
✅ 127 untouched benchmarks
⏩ 131 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	`BASE`	`HEAD`	Efficiency
❌	`merge`	70.7 µs	138.2 µs	-48.85%
⚡	`merge`	173.7 µs	73.7 µs	×2.4
⚡	`merge`	279.9 µs	187.8 µs	+49.04%
⚡	`merge`	357.3 µs	267.5 µs	+33.55%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing frenzzy:sf-path-addressing (3988224) with next (e8c8947)}

131 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

rc.4 publishes the path-addressed server function calls this branch routes (solidjs/solid#3076): the client computes `<endpoint>/<id>` and the published server handler resolves the id from the path alone — the X-Server-Function-Id header and `?id=` forms are gone from the runtime, not just retired client-side. The workspace catalog moves to ^2.0.0-rc.4 (minimumReleaseAgeExclude extended per the existing pattern), and the start-ssr suite's synthetic dispatches switch from `?id=` to the path form, since the published handler no longer answers the legacy shape. The plugin's own transitional fallbacks stay: they serve runtimes older than the addressing change, which the peer range still admits. Full gate green against published rc.4 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

The dist-types check failed because the lockfile still resolved @solidjs/web 2.0.0-rc.3, which predates parseServerFunctionUrl — the runtime half of the addressing scheme this branch adopts. The peer and dev floors now say what the code means: ^2.0.0-rc.4. The vite plugin moves to 3.0.0-next.35 (the plugin half of solidjs/solid#3076), which requires vite 8, which requires vitest 4 — test-toolchain-only, but vitest 4 constructs `new FormData()` through the mock's implementation, so the arrow-function stubs become real functions (arrows aren't constructable), and one Mock type annotation gains its signature. Co-authored-by: Cursor <cursoragent@cursor.com>

frenzzy · 2026-08-27T05:05:21Z

Implements the split settled in #3072: the id moves to the path, the arguments stay in the query.

The first revision of this PR put arguments in the path too. That's withdrawn — two of the objections landed. Bound arguments ride urls on POSTs as well, where path placement buys nothing and turns the url into a hybrid of path-baked arguments plus a body; and query-scrubbing is ubiquitous in log tooling while path-scrubbing isn't, which matters when arguments carry emails and search terms. The remaining case for path-baked arguments was resilience against a zone configured to ignore query strings, and with the id in the path that failure is already bounded to one function's arguments rather than serving another function's response — a config bug to document, not a reason to contort the scheme.

What changes

<endpoint>/<id> for GET and POST alike.fn.url is /_server/<id>; arguments stay in ?args=, unchanged in encoding.
X-Server-Function-Id is gone — from the wire and from the package's exports. With the id nowhere but the url, a cache in front of the app cannot be made to store one function's response under another's key, which closesX-Server-Function-Id overrides the id in the URL, making it an unkeyed input to a cacheable response #3070 by construction rather than by rule. X-Server-Function-Instance still marks a scripted call.
serverFunctionUrl(id, boundArgs?) / parseServerFunctionUrl(url) on both entries, resolved against the configured endpoint. This is your "export a URL builder" note: solid-router composes form-action urls with bound arguments for the no-JS path, and it currently recovers the id with new URL(url, mockBase).searchParams.get("id") (src/data/action.ts) — that line becomes parseServerFunctionUrl(url). It's the only coupling: the router passes the url on to createServerReference(id, undefined, url), which still targets a base verbatim.
URL length falls back to POST. A GET call whose encoded url would exceed 2000 characters dispatches over POST instead — declaring GET grants the read methods without revoking the default transport, so the call still runs, it just isn't cacheable. A cache miss, not a 414 from whichever proxy draws the line first.
method="get" forms work (second commit, droppable on its own). A GET submit replaces the action url's query with the form's fields — only an address in the path survives one — and those fields now reach the function as a lone URLSearchParams, the read-side mirror of a no-JS form post decoding to a lone FormData.

On your other two notes: argument encoding is left exactly as it was, since positional arguments are ordered by construction and need no canonicalization layer (the one residue is object key order inside an argument, which is a JSON property, not an addressing one); and deploy skew is treated as a docs matter, with no machinery added.

Shape of the change

188 lines of runtime across the three files, most of it comments. Both halves build and parse the address through one pair of functions in shared.ts (serverFunctionAddress / parseServerFunctionAddress), which also retires a standing hazard: endpoint had to be configured identically on client and server by hand, and there was no shared definition of what it produced. live inherits the address through fn.url; frameAddress is untouched (a logical region address, not a url). A path carrying more than the one segment the address gives meaning to answers 404 rather than matching on its prefix.

Which reading a url gets is decided by the url alone

Worth calling out because the first cut of the second commit got it wrong: the choice between "this query is an argument encoding" and "this query is a form's fields" keys on the url only, never on the instance header. Otherwise a GET-declared function with cache-control: public answers the same url with two different bodies depending on a header no cache keys on and no Vary names — a cross-site prefetch could force one variant into the entry every scripted client then reads, which is the axis #3070 is about. args stays reserved on the query, and a value under it that is not an argument array answers 400 for every caller of that url rather than spreading into whatever the encoding produced.

Verification

pnpm test at the root: 32/32 turbo tasks green, rebased on next @ 258c76a. @solidjs/web across its three configs: 609 + 322 + 146. The addressing spec is 20 cases against the built bundles: the GET and POST addresses, the POST fallback and its url-length boundary, that the fallback stays a read (no single-flight collection), bound arguments with a FormData body over the real no-JS post, the refusal to render bound arguments JSON cannot carry, the same-url-same-answer invariant, args degenerate encodings answering 400, the id header and ?id= no longer addressing anything, the query reading on GET and HEAD, building and parsing action urls from both entries, a mount path with a trailing slash, a request outside the mount, an id with characters the path must encode, and the 404s for a bare, trailing-slash, or over-long path. Existing specs that hand-built the old wire shape are updated — including server-functions-http-hygiene.spec.tsx from 258c76a — and RFC 10 is updated where it describes the format.

Two red checks (job, Run benchmarks) fail the same way on next itself at 258c76a — Failed: @solidjs/element#test, a package this branch doesn't touch.

Known limits, stated rather than hidden

A method="get" submit reaches the function, but what the browser then renders is the raw serialized result: handleNoJS's redirect convention is a form-post one (isFormPost is POST-only), so a read that wants to render something should return a Response. Deliberate — redirecting a read would lose the thing the read produced.
A URLSearchParams argument has no encoding on the GET query path (isJSONSafe rejects it), so the shape the form convention produces cannot be sent by a scripted GET. The symmetric fix — a lone URLSearchParams argument becoming the query itself, which would make the scripted and unscripted urls identical — is a natural follow-up, left out to keep this a pure addressing change.
parseServerFunctionUrl reads the path only; a caller that cares whether a url is its own origin checks that itself.

Relationship to `258c76a`

The method allowlist and cache hygiene need nothing from this change and vice versa; the rebase only touched that commit's new spec request builders. One interaction is deliberate: HEAD is a read that mirrors GET, so an unscripted HEAD gets the same lone URLSearchParams a GET would — a HEAD to a form url describes the GET response, arguments included.

changeset-bot · 2026-08-27T05:05:26Z

🦋 Changeset detected

Latest commit: 3988224

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
test-integration	Patch
solid-js	Patch
@solidjs/compiler	Patch
@solidjs/universal	Patch
@solidjs/signals	Patch
@solidjs/diagnostics	Patch

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

The function id travelled in `X-Server-Function-Id`, with `?id=` as the fallback for requests the client runtime did not make. Both are gone; it moves into the path — `<endpoint>/<id>` — which is what per-function policy keys on: edge rules, cache policies by path pattern, rate limits, log aggregation, `http.route` labels in traces. It also leaves exactly one place in the request carrying the id, which closessolidjs#3070 by construction: with no header to override the url, a cache in front of the app cannot be made to store one function's response under another's key. POST addresses move too — no caching reason, the same legibility — and that is what lets the header disappear entirely instead of surviving as the POST addressing channel. `endpoint` gates dispatch on both halves as a result: a request whose path does not start with it is not a call. Arguments stay in the query, where caches key on them, log tooling scrubs them, path normalization leaves them alone, and bound arguments already ride for form posts. A value under `args` that is not an argument array answers 400 rather than spreading into whatever the encoding happened to produce. A GET call whose url would exceed 2000 characters — measured on the wire, origin included — dispatches over POST instead, marked as a read so it asks for no single-flight collection: a cache miss rather than a 414 from whichever proxy in the chain draws the line first. `serverFunctionUrl(id, boundArgs?)` and `parseServerFunctionUrl(url)` export the two halves of the scheme from both entries, so integrations composing action urls build them through the runtime rather than hand-rolling the shape.

A `method="get"` form submit replaces the action url's query with the form's fields — which is why only an address in the path survives one — so a read whose query is not an argument encoding is carrying a form, not arguments. That query now reaches the function as a lone `URLSearchParams`, the read-side mirror of a no-JS form post decoding to a lone `FormData`: <form method="get" action={search.url}> <input name="q" /> </form>  Which reading applies is decided by the url alone, never by a header: a cache keys on the url, so the same url has to mean the same call whether or not the client runtime made it. HEAD reads it the same way as the GET it mirrors. What a GET submit renders is the function's to shape — the no-JS redirect convention is a form-post one, and a read has something to say.

codspeed-hq · 2026-08-27T07:28:05Z

Merging this PR will regress 1 benchmark

⚠️

Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.
Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
❌ 1 regressed benchmark
✅ 127 untouched benchmarks
⏩ 131 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	`BASE`	`HEAD`	Efficiency
❌	`merge`	70.7 µs	138.2 µs	-48.85%
⚡	`merge`	173.7 µs	73.7 µs	×2.4
⚡	`merge`	279.9 µs	187.8 µs	+49.04%
⚡	`merge`	357.3 µs	267.5 µs	+33.55%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing frenzzy:sf-path-addressing (3988224) with next (e8c8947)}

131 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

rc.4 publishes the path-addressed server function calls this branch routes (solidjs/solid#3076): the client computes `<endpoint>/<id>` and the published server handler resolves the id from the path alone — the X-Server-Function-Id header and `?id=` forms are gone from the runtime, not just retired client-side. The workspace catalog moves to ^2.0.0-rc.4 (minimumReleaseAgeExclude extended per the existing pattern), and the start-ssr suite's synthetic dispatches switch from `?id=` to the path form, since the published handler no longer answers the legacy shape. The plugin's own transitional fallbacks stay: they serve runtimes older than the addressing change, which the peer range still admits. Full gate green against published rc.4 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

The dist-types check failed because the lockfile still resolved @solidjs/web 2.0.0-rc.3, which predates parseServerFunctionUrl — the runtime half of the addressing scheme this branch adopts. The peer and dev floors now say what the code means: ^2.0.0-rc.4. The vite plugin moves to 3.0.0-next.35 (the plugin half of solidjs/solid#3076), which requires vite 8, which requires vitest 4 — test-toolchain-only, but vitest 4 constructs `new FormData()` through the mock's implementation, so the arrow-function stubs become real functions (arrows aren't constructable), and one Mock type annotation gains its signature. Co-authored-by: Cursor <cursoragent@cursor.com>

frenzzy · 2026-08-27T05:05:21Z

Implements the split settled in #3072: the id moves to the path, the arguments stay in the query.

The first revision of this PR put arguments in the path too. That's withdrawn — two of the objections landed. Bound arguments ride urls on POSTs as well, where path placement buys nothing and turns the url into a hybrid of path-baked arguments plus a body; and query-scrubbing is ubiquitous in log tooling while path-scrubbing isn't, which matters when arguments carry emails and search terms. The remaining case for path-baked arguments was resilience against a zone configured to ignore query strings, and with the id in the path that failure is already bounded to one function's arguments rather than serving another function's response — a config bug to document, not a reason to contort the scheme.

What changes

<endpoint>/<id> for GET and POST alike.fn.url is /_server/<id>; arguments stay in ?args=, unchanged in encoding.
X-Server-Function-Id is gone — from the wire and from the package's exports. With the id nowhere but the url, a cache in front of the app cannot be made to store one function's response under another's key, which closesX-Server-Function-Id overrides the id in the URL, making it an unkeyed input to a cacheable response #3070 by construction rather than by rule. X-Server-Function-Instance still marks a scripted call.
serverFunctionUrl(id, boundArgs?) / parseServerFunctionUrl(url) on both entries, resolved against the configured endpoint. This is your "export a URL builder" note: solid-router composes form-action urls with bound arguments for the no-JS path, and it currently recovers the id with new URL(url, mockBase).searchParams.get("id") (src/data/action.ts) — that line becomes parseServerFunctionUrl(url). It's the only coupling: the router passes the url on to createServerReference(id, undefined, url), which still targets a base verbatim.
URL length falls back to POST. A GET call whose encoded url would exceed 2000 characters dispatches over POST instead — declaring GET grants the read methods without revoking the default transport, so the call still runs, it just isn't cacheable. A cache miss, not a 414 from whichever proxy draws the line first.
method="get" forms work (second commit, droppable on its own). A GET submit replaces the action url's query with the form's fields — only an address in the path survives one — and those fields now reach the function as a lone URLSearchParams, the read-side mirror of a no-JS form post decoding to a lone FormData.

On your other two notes: argument encoding is left exactly as it was, since positional arguments are ordered by construction and need no canonicalization layer (the one residue is object key order inside an argument, which is a JSON property, not an addressing one); and deploy skew is treated as a docs matter, with no machinery added.

Shape of the change

188 lines of runtime across the three files, most of it comments. Both halves build and parse the address through one pair of functions in shared.ts (serverFunctionAddress / parseServerFunctionAddress), which also retires a standing hazard: endpoint had to be configured identically on client and server by hand, and there was no shared definition of what it produced. live inherits the address through fn.url; frameAddress is untouched (a logical region address, not a url). A path carrying more than the one segment the address gives meaning to answers 404 rather than matching on its prefix.

Which reading a url gets is decided by the url alone

Worth calling out because the first cut of the second commit got it wrong: the choice between "this query is an argument encoding" and "this query is a form's fields" keys on the url only, never on the instance header. Otherwise a GET-declared function with cache-control: public answers the same url with two different bodies depending on a header no cache keys on and no Vary names — a cross-site prefetch could force one variant into the entry every scripted client then reads, which is the axis #3070 is about. args stays reserved on the query, and a value under it that is not an argument array answers 400 for every caller of that url rather than spreading into whatever the encoding produced.

Verification

pnpm test at the root: 32/32 turbo tasks green, rebased on next @ 258c76a. @solidjs/web across its three configs: 609 + 322 + 146. The addressing spec is 20 cases against the built bundles: the GET and POST addresses, the POST fallback and its url-length boundary, that the fallback stays a read (no single-flight collection), bound arguments with a FormData body over the real no-JS post, the refusal to render bound arguments JSON cannot carry, the same-url-same-answer invariant, args degenerate encodings answering 400, the id header and ?id= no longer addressing anything, the query reading on GET and HEAD, building and parsing action urls from both entries, a mount path with a trailing slash, a request outside the mount, an id with characters the path must encode, and the 404s for a bare, trailing-slash, or over-long path. Existing specs that hand-built the old wire shape are updated — including server-functions-http-hygiene.spec.tsx from 258c76a — and RFC 10 is updated where it describes the format.

Two red checks (job, Run benchmarks) fail the same way on next itself at 258c76a — Failed: @solidjs/element#test, a package this branch doesn't touch.

Known limits, stated rather than hidden

A method="get" submit reaches the function, but what the browser then renders is the raw serialized result: handleNoJS's redirect convention is a form-post one (isFormPost is POST-only), so a read that wants to render something should return a Response. Deliberate — redirecting a read would lose the thing the read produced.
A URLSearchParams argument has no encoding on the GET query path (isJSONSafe rejects it), so the shape the form convention produces cannot be sent by a scripted GET. The symmetric fix — a lone URLSearchParams argument becoming the query itself, which would make the scripted and unscripted urls identical — is a natural follow-up, left out to keep this a pure addressing change.
parseServerFunctionUrl reads the path only; a caller that cares whether a url is its own origin checks that itself.

Relationship to `258c76a`

The method allowlist and cache hygiene need nothing from this change and vice versa; the rebase only touched that commit's new spec request builders. One interaction is deliberate: HEAD is a read that mirrors GET, so an unscripted HEAD gets the same lone URLSearchParams a GET would — a HEAD to a form url describes the GET response, arguments included.

changeset-bot · 2026-08-27T05:05:26Z

🦋 Changeset detected

Latest commit: 3988224

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
test-integration	Patch
solid-js	Patch
@solidjs/compiler	Patch
@solidjs/universal	Patch
@solidjs/signals	Patch
@solidjs/diagnostics	Patch

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

The function id travelled in `X-Server-Function-Id`, with `?id=` as the fallback for requests the client runtime did not make. Both are gone; it moves into the path — `<endpoint>/<id>` — which is what per-function policy keys on: edge rules, cache policies by path pattern, rate limits, log aggregation, `http.route` labels in traces. It also leaves exactly one place in the request carrying the id, which closessolidjs#3070 by construction: with no header to override the url, a cache in front of the app cannot be made to store one function's response under another's key. POST addresses move too — no caching reason, the same legibility — and that is what lets the header disappear entirely instead of surviving as the POST addressing channel. `endpoint` gates dispatch on both halves as a result: a request whose path does not start with it is not a call. Arguments stay in the query, where caches key on them, log tooling scrubs them, path normalization leaves them alone, and bound arguments already ride for form posts. A value under `args` that is not an argument array answers 400 rather than spreading into whatever the encoding happened to produce. A GET call whose url would exceed 2000 characters — measured on the wire, origin included — dispatches over POST instead, marked as a read so it asks for no single-flight collection: a cache miss rather than a 414 from whichever proxy in the chain draws the line first. `serverFunctionUrl(id, boundArgs?)` and `parseServerFunctionUrl(url)` export the two halves of the scheme from both entries, so integrations composing action urls build them through the runtime rather than hand-rolling the shape.

A `method="get"` form submit replaces the action url's query with the form's fields — which is why only an address in the path survives one — so a read whose query is not an argument encoding is carrying a form, not arguments. That query now reaches the function as a lone `URLSearchParams`, the read-side mirror of a no-JS form post decoding to a lone `FormData`: <form method="get" action={search.url}> <input name="q" /> </form>  Which reading applies is decided by the url alone, never by a header: a cache keys on the url, so the same url has to mean the same call whether or not the client runtime made it. HEAD reads it the same way as the GET it mirrors. What a GET submit renders is the function's to shape — the no-JS redirect convention is a form-post one, and a read has something to say.

codspeed-hq · 2026-08-27T07:28:05Z

Merging this PR will regress 1 benchmark

⚠️

Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.
Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
❌ 1 regressed benchmark
✅ 127 untouched benchmarks
⏩ 131 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	`BASE`	`HEAD`	Efficiency
❌	`merge`	70.7 µs	138.2 µs	-48.85%
⚡	`merge`	173.7 µs	73.7 µs	×2.4
⚡	`merge`	279.9 µs	187.8 µs	+49.04%
⚡	`merge`	357.3 µs	267.5 µs	+33.55%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing frenzzy:sf-path-addressing (3988224) with next (e8c8947)}

131 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

rc.4 publishes the path-addressed server function calls this branch routes (solidjs/solid#3076): the client computes `<endpoint>/<id>` and the published server handler resolves the id from the path alone — the X-Server-Function-Id header and `?id=` forms are gone from the runtime, not just retired client-side. The workspace catalog moves to ^2.0.0-rc.4 (minimumReleaseAgeExclude extended per the existing pattern), and the start-ssr suite's synthetic dispatches switch from `?id=` to the path form, since the published handler no longer answers the legacy shape. The plugin's own transitional fallbacks stay: they serve runtimes older than the addressing change, which the peer range still admits. Full gate green against published rc.4 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

The dist-types check failed because the lockfile still resolved @solidjs/web 2.0.0-rc.3, which predates parseServerFunctionUrl — the runtime half of the addressing scheme this branch adopts. The peer and dev floors now say what the code means: ^2.0.0-rc.4. The vite plugin moves to 3.0.0-next.35 (the plugin half of solidjs/solid#3076), which requires vite 8, which requires vitest 4 — test-toolchain-only, but vitest 4 constructs `new FormData()` through the mock's implementation, so the arrow-function stubs become real functions (arrows aren't constructable), and one Mock type annotation gains its signature. Co-authored-by: Cursor <cursoragent@cursor.com>

frenzzy · 2026-08-27T05:05:21Z

Implements the split settled in #3072: the id moves to the path, the arguments stay in the query.

The first revision of this PR put arguments in the path too. That's withdrawn — two of the objections landed. Bound arguments ride urls on POSTs as well, where path placement buys nothing and turns the url into a hybrid of path-baked arguments plus a body; and query-scrubbing is ubiquitous in log tooling while path-scrubbing isn't, which matters when arguments carry emails and search terms. The remaining case for path-baked arguments was resilience against a zone configured to ignore query strings, and with the id in the path that failure is already bounded to one function's arguments rather than serving another function's response — a config bug to document, not a reason to contort the scheme.

What changes

<endpoint>/<id> for GET and POST alike.fn.url is /_server/<id>; arguments stay in ?args=, unchanged in encoding.
X-Server-Function-Id is gone — from the wire and from the package's exports. With the id nowhere but the url, a cache in front of the app cannot be made to store one function's response under another's key, which closesX-Server-Function-Id overrides the id in the URL, making it an unkeyed input to a cacheable response #3070 by construction rather than by rule. X-Server-Function-Instance still marks a scripted call.
serverFunctionUrl(id, boundArgs?) / parseServerFunctionUrl(url) on both entries, resolved against the configured endpoint. This is your "export a URL builder" note: solid-router composes form-action urls with bound arguments for the no-JS path, and it currently recovers the id with new URL(url, mockBase).searchParams.get("id") (src/data/action.ts) — that line becomes parseServerFunctionUrl(url). It's the only coupling: the router passes the url on to createServerReference(id, undefined, url), which still targets a base verbatim.
URL length falls back to POST. A GET call whose encoded url would exceed 2000 characters dispatches over POST instead — declaring GET grants the read methods without revoking the default transport, so the call still runs, it just isn't cacheable. A cache miss, not a 414 from whichever proxy draws the line first.
method="get" forms work (second commit, droppable on its own). A GET submit replaces the action url's query with the form's fields — only an address in the path survives one — and those fields now reach the function as a lone URLSearchParams, the read-side mirror of a no-JS form post decoding to a lone FormData.

On your other two notes: argument encoding is left exactly as it was, since positional arguments are ordered by construction and need no canonicalization layer (the one residue is object key order inside an argument, which is a JSON property, not an addressing one); and deploy skew is treated as a docs matter, with no machinery added.

Shape of the change

188 lines of runtime across the three files, most of it comments. Both halves build and parse the address through one pair of functions in shared.ts (serverFunctionAddress / parseServerFunctionAddress), which also retires a standing hazard: endpoint had to be configured identically on client and server by hand, and there was no shared definition of what it produced. live inherits the address through fn.url; frameAddress is untouched (a logical region address, not a url). A path carrying more than the one segment the address gives meaning to answers 404 rather than matching on its prefix.

Which reading a url gets is decided by the url alone

Worth calling out because the first cut of the second commit got it wrong: the choice between "this query is an argument encoding" and "this query is a form's fields" keys on the url only, never on the instance header. Otherwise a GET-declared function with cache-control: public answers the same url with two different bodies depending on a header no cache keys on and no Vary names — a cross-site prefetch could force one variant into the entry every scripted client then reads, which is the axis #3070 is about. args stays reserved on the query, and a value under it that is not an argument array answers 400 for every caller of that url rather than spreading into whatever the encoding produced.

Verification

pnpm test at the root: 32/32 turbo tasks green, rebased on next @ 258c76a. @solidjs/web across its three configs: 609 + 322 + 146. The addressing spec is 20 cases against the built bundles: the GET and POST addresses, the POST fallback and its url-length boundary, that the fallback stays a read (no single-flight collection), bound arguments with a FormData body over the real no-JS post, the refusal to render bound arguments JSON cannot carry, the same-url-same-answer invariant, args degenerate encodings answering 400, the id header and ?id= no longer addressing anything, the query reading on GET and HEAD, building and parsing action urls from both entries, a mount path with a trailing slash, a request outside the mount, an id with characters the path must encode, and the 404s for a bare, trailing-slash, or over-long path. Existing specs that hand-built the old wire shape are updated — including server-functions-http-hygiene.spec.tsx from 258c76a — and RFC 10 is updated where it describes the format.

Two red checks (job, Run benchmarks) fail the same way on next itself at 258c76a — Failed: @solidjs/element#test, a package this branch doesn't touch.

Known limits, stated rather than hidden

A method="get" submit reaches the function, but what the browser then renders is the raw serialized result: handleNoJS's redirect convention is a form-post one (isFormPost is POST-only), so a read that wants to render something should return a Response. Deliberate — redirecting a read would lose the thing the read produced.
A URLSearchParams argument has no encoding on the GET query path (isJSONSafe rejects it), so the shape the form convention produces cannot be sent by a scripted GET. The symmetric fix — a lone URLSearchParams argument becoming the query itself, which would make the scripted and unscripted urls identical — is a natural follow-up, left out to keep this a pure addressing change.
parseServerFunctionUrl reads the path only; a caller that cares whether a url is its own origin checks that itself.

Relationship to `258c76a`

The method allowlist and cache hygiene need nothing from this change and vice versa; the rebase only touched that commit's new spec request builders. One interaction is deliberate: HEAD is a read that mirrors GET, so an unscripted HEAD gets the same lone URLSearchParams a GET would — a HEAD to a form url describes the GET response, arguments included.

changeset-bot · 2026-08-27T05:05:26Z

🦋 Changeset detected

Latest commit: 3988224

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
test-integration	Patch
solid-js	Patch
@solidjs/compiler	Patch
@solidjs/universal	Patch
@solidjs/signals	Patch
@solidjs/diagnostics	Patch

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

The function id travelled in `X-Server-Function-Id`, with `?id=` as the fallback for requests the client runtime did not make. Both are gone; it moves into the path — `<endpoint>/<id>` — which is what per-function policy keys on: edge rules, cache policies by path pattern, rate limits, log aggregation, `http.route` labels in traces. It also leaves exactly one place in the request carrying the id, which closessolidjs#3070 by construction: with no header to override the url, a cache in front of the app cannot be made to store one function's response under another's key. POST addresses move too — no caching reason, the same legibility — and that is what lets the header disappear entirely instead of surviving as the POST addressing channel. `endpoint` gates dispatch on both halves as a result: a request whose path does not start with it is not a call. Arguments stay in the query, where caches key on them, log tooling scrubs them, path normalization leaves them alone, and bound arguments already ride for form posts. A value under `args` that is not an argument array answers 400 rather than spreading into whatever the encoding happened to produce. A GET call whose url would exceed 2000 characters — measured on the wire, origin included — dispatches over POST instead, marked as a read so it asks for no single-flight collection: a cache miss rather than a 414 from whichever proxy in the chain draws the line first. `serverFunctionUrl(id, boundArgs?)` and `parseServerFunctionUrl(url)` export the two halves of the scheme from both entries, so integrations composing action urls build them through the runtime rather than hand-rolling the shape.

A `method="get"` form submit replaces the action url's query with the form's fields — which is why only an address in the path survives one — so a read whose query is not an argument encoding is carrying a form, not arguments. That query now reaches the function as a lone `URLSearchParams`, the read-side mirror of a no-JS form post decoding to a lone `FormData`: <form method="get" action={search.url}> <input name="q" /> </form>  Which reading applies is decided by the url alone, never by a header: a cache keys on the url, so the same url has to mean the same call whether or not the client runtime made it. HEAD reads it the same way as the GET it mirrors. What a GET submit renders is the function's to shape — the no-JS redirect convention is a form-post one, and a read has something to say.

codspeed-hq · 2026-08-27T07:28:05Z

Merging this PR will regress 1 benchmark

⚠️

Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.
Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
❌ 1 regressed benchmark
✅ 127 untouched benchmarks
⏩ 131 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	`BASE`	`HEAD`	Efficiency
❌	`merge`	70.7 µs	138.2 µs	-48.85%
⚡	`merge`	173.7 µs	73.7 µs	×2.4
⚡	`merge`	279.9 µs	187.8 µs	+49.04%
⚡	`merge`	357.3 µs	267.5 µs	+33.55%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing frenzzy:sf-path-addressing (3988224) with next (e8c8947)}

131 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

rc.4 publishes the path-addressed server function calls this branch routes (solidjs/solid#3076): the client computes `<endpoint>/<id>` and the published server handler resolves the id from the path alone — the X-Server-Function-Id header and `?id=` forms are gone from the runtime, not just retired client-side. The workspace catalog moves to ^2.0.0-rc.4 (minimumReleaseAgeExclude extended per the existing pattern), and the start-ssr suite's synthetic dispatches switch from `?id=` to the path form, since the published handler no longer answers the legacy shape. The plugin's own transitional fallbacks stay: they serve runtimes older than the addressing change, which the peer range still admits. Full gate green against published rc.4 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

The dist-types check failed because the lockfile still resolved @solidjs/web 2.0.0-rc.3, which predates parseServerFunctionUrl — the runtime half of the addressing scheme this branch adopts. The peer and dev floors now say what the code means: ^2.0.0-rc.4. The vite plugin moves to 3.0.0-next.35 (the plugin half of solidjs/solid#3076), which requires vite 8, which requires vitest 4 — test-toolchain-only, but vitest 4 constructs `new FormData()` through the mock's implementation, so the arrow-function stubs become real functions (arrows aren't constructable), and one Mock type annotation gains its signature. Co-authored-by: Cursor <cursoragent@cursor.com>

frenzzy · 2026-08-27T05:05:21Z

Implements the split settled in #3072: the id moves to the path, the arguments stay in the query.

The first revision of this PR put arguments in the path too. That's withdrawn — two of the objections landed. Bound arguments ride urls on POSTs as well, where path placement buys nothing and turns the url into a hybrid of path-baked arguments plus a body; and query-scrubbing is ubiquitous in log tooling while path-scrubbing isn't, which matters when arguments carry emails and search terms. The remaining case for path-baked arguments was resilience against a zone configured to ignore query strings, and with the id in the path that failure is already bounded to one function's arguments rather than serving another function's response — a config bug to document, not a reason to contort the scheme.

What changes

<endpoint>/<id> for GET and POST alike.fn.url is /_server/<id>; arguments stay in ?args=, unchanged in encoding.
X-Server-Function-Id is gone — from the wire and from the package's exports. With the id nowhere but the url, a cache in front of the app cannot be made to store one function's response under another's key, which closesX-Server-Function-Id overrides the id in the URL, making it an unkeyed input to a cacheable response #3070 by construction rather than by rule. X-Server-Function-Instance still marks a scripted call.
serverFunctionUrl(id, boundArgs?) / parseServerFunctionUrl(url) on both entries, resolved against the configured endpoint. This is your "export a URL builder" note: solid-router composes form-action urls with bound arguments for the no-JS path, and it currently recovers the id with new URL(url, mockBase).searchParams.get("id") (src/data/action.ts) — that line becomes parseServerFunctionUrl(url). It's the only coupling: the router passes the url on to createServerReference(id, undefined, url), which still targets a base verbatim.
URL length falls back to POST. A GET call whose encoded url would exceed 2000 characters dispatches over POST instead — declaring GET grants the read methods without revoking the default transport, so the call still runs, it just isn't cacheable. A cache miss, not a 414 from whichever proxy draws the line first.
method="get" forms work (second commit, droppable on its own). A GET submit replaces the action url's query with the form's fields — only an address in the path survives one — and those fields now reach the function as a lone URLSearchParams, the read-side mirror of a no-JS form post decoding to a lone FormData.

On your other two notes: argument encoding is left exactly as it was, since positional arguments are ordered by construction and need no canonicalization layer (the one residue is object key order inside an argument, which is a JSON property, not an addressing one); and deploy skew is treated as a docs matter, with no machinery added.

Shape of the change

188 lines of runtime across the three files, most of it comments. Both halves build and parse the address through one pair of functions in shared.ts (serverFunctionAddress / parseServerFunctionAddress), which also retires a standing hazard: endpoint had to be configured identically on client and server by hand, and there was no shared definition of what it produced. live inherits the address through fn.url; frameAddress is untouched (a logical region address, not a url). A path carrying more than the one segment the address gives meaning to answers 404 rather than matching on its prefix.

Which reading a url gets is decided by the url alone

Worth calling out because the first cut of the second commit got it wrong: the choice between "this query is an argument encoding" and "this query is a form's fields" keys on the url only, never on the instance header. Otherwise a GET-declared function with cache-control: public answers the same url with two different bodies depending on a header no cache keys on and no Vary names — a cross-site prefetch could force one variant into the entry every scripted client then reads, which is the axis #3070 is about. args stays reserved on the query, and a value under it that is not an argument array answers 400 for every caller of that url rather than spreading into whatever the encoding produced.

Verification

pnpm test at the root: 32/32 turbo tasks green, rebased on next @ 258c76a. @solidjs/web across its three configs: 609 + 322 + 146. The addressing spec is 20 cases against the built bundles: the GET and POST addresses, the POST fallback and its url-length boundary, that the fallback stays a read (no single-flight collection), bound arguments with a FormData body over the real no-JS post, the refusal to render bound arguments JSON cannot carry, the same-url-same-answer invariant, args degenerate encodings answering 400, the id header and ?id= no longer addressing anything, the query reading on GET and HEAD, building and parsing action urls from both entries, a mount path with a trailing slash, a request outside the mount, an id with characters the path must encode, and the 404s for a bare, trailing-slash, or over-long path. Existing specs that hand-built the old wire shape are updated — including server-functions-http-hygiene.spec.tsx from 258c76a — and RFC 10 is updated where it describes the format.

Two red checks (job, Run benchmarks) fail the same way on next itself at 258c76a — Failed: @solidjs/element#test, a package this branch doesn't touch.

Known limits, stated rather than hidden

A method="get" submit reaches the function, but what the browser then renders is the raw serialized result: handleNoJS's redirect convention is a form-post one (isFormPost is POST-only), so a read that wants to render something should return a Response. Deliberate — redirecting a read would lose the thing the read produced.
A URLSearchParams argument has no encoding on the GET query path (isJSONSafe rejects it), so the shape the form convention produces cannot be sent by a scripted GET. The symmetric fix — a lone URLSearchParams argument becoming the query itself, which would make the scripted and unscripted urls identical — is a natural follow-up, left out to keep this a pure addressing change.
parseServerFunctionUrl reads the path only; a caller that cares whether a url is its own origin checks that itself.

Relationship to `258c76a`

The method allowlist and cache hygiene need nothing from this change and vice versa; the rebase only touched that commit's new spec request builders. One interaction is deliberate: HEAD is a read that mirrors GET, so an unscripted HEAD gets the same lone URLSearchParams a GET would — a HEAD to a form url describes the GET response, arguments included.

changeset-bot · 2026-08-27T05:05:26Z

🦋 Changeset detected

Latest commit: 3988224

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
test-integration	Patch
solid-js	Patch
@solidjs/compiler	Patch
@solidjs/universal	Patch
@solidjs/signals	Patch
@solidjs/diagnostics	Patch

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

The function id travelled in `X-Server-Function-Id`, with `?id=` as the fallback for requests the client runtime did not make. Both are gone; it moves into the path — `<endpoint>/<id>` — which is what per-function policy keys on: edge rules, cache policies by path pattern, rate limits, log aggregation, `http.route` labels in traces. It also leaves exactly one place in the request carrying the id, which closessolidjs#3070 by construction: with no header to override the url, a cache in front of the app cannot be made to store one function's response under another's key. POST addresses move too — no caching reason, the same legibility — and that is what lets the header disappear entirely instead of surviving as the POST addressing channel. `endpoint` gates dispatch on both halves as a result: a request whose path does not start with it is not a call. Arguments stay in the query, where caches key on them, log tooling scrubs them, path normalization leaves them alone, and bound arguments already ride for form posts. A value under `args` that is not an argument array answers 400 rather than spreading into whatever the encoding happened to produce. A GET call whose url would exceed 2000 characters — measured on the wire, origin included — dispatches over POST instead, marked as a read so it asks for no single-flight collection: a cache miss rather than a 414 from whichever proxy in the chain draws the line first. `serverFunctionUrl(id, boundArgs?)` and `parseServerFunctionUrl(url)` export the two halves of the scheme from both entries, so integrations composing action urls build them through the runtime rather than hand-rolling the shape.

A `method="get"` form submit replaces the action url's query with the form's fields — which is why only an address in the path survives one — so a read whose query is not an argument encoding is carrying a form, not arguments. That query now reaches the function as a lone `URLSearchParams`, the read-side mirror of a no-JS form post decoding to a lone `FormData`: <form method="get" action={search.url}> <input name="q" /> </form>  Which reading applies is decided by the url alone, never by a header: a cache keys on the url, so the same url has to mean the same call whether or not the client runtime made it. HEAD reads it the same way as the GET it mirrors. What a GET submit renders is the function's to shape — the no-JS redirect convention is a form-post one, and a read has something to say.

codspeed-hq · 2026-08-27T07:28:05Z

Merging this PR will regress 1 benchmark

⚠️

Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.
Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
❌ 1 regressed benchmark
✅ 127 untouched benchmarks
⏩ 131 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	`BASE`	`HEAD`	Efficiency
❌	`merge`	70.7 µs	138.2 µs	-48.85%
⚡	`merge`	173.7 µs	73.7 µs	×2.4
⚡	`merge`	279.9 µs	187.8 µs	+49.04%
⚡	`merge`	357.3 µs	267.5 µs	+33.55%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing frenzzy:sf-path-addressing (3988224) with next (e8c8947)}

131 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

rc.4 publishes the path-addressed server function calls this branch routes (solidjs/solid#3076): the client computes `<endpoint>/<id>` and the published server handler resolves the id from the path alone — the X-Server-Function-Id header and `?id=` forms are gone from the runtime, not just retired client-side. The workspace catalog moves to ^2.0.0-rc.4 (minimumReleaseAgeExclude extended per the existing pattern), and the start-ssr suite's synthetic dispatches switch from `?id=` to the path form, since the published handler no longer answers the legacy shape. The plugin's own transitional fallbacks stay: they serve runtimes older than the addressing change, which the peer range still admits. Full gate green against published rc.4 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

The dist-types check failed because the lockfile still resolved @solidjs/web 2.0.0-rc.3, which predates parseServerFunctionUrl — the runtime half of the addressing scheme this branch adopts. The peer and dev floors now say what the code means: ^2.0.0-rc.4. The vite plugin moves to 3.0.0-next.35 (the plugin half of solidjs/solid#3076), which requires vite 8, which requires vitest 4 — test-toolchain-only, but vitest 4 constructs `new FormData()` through the mock's implementation, so the arrow-function stubs become real functions (arrows aren't constructable), and one Mock type annotation gains its signature. Co-authored-by: Cursor <cursoragent@cursor.com>

frenzzy force-pushed the sf-path-addressing branch 4 times, most recently from 575e36c to b76fc66Compare August 27, 2026 06:16

frenzzy added 2 commits August 27, 2026 14:15

frenzzy force-pushed the sf-path-addressing branch from b76fc66 to 3988224Compare August 27, 2026 07:16

ryansolid merged commit 79b96cf into solidjs:nextAug 27, 2026
6 of 7 checks passed

ryansolid mentioned this pull request Aug 27, 2026
Adopt path-based server function addressing solidjs/solid-router#590
Merged
2 tasks

frenzzy mentioned this pull request Aug 27, 2026
X-Server-Function-Id overrides the id in the URL, making it an unkeyed input to a cacheable response #3070
Closed

ryansolid mentioned this pull request Aug 27, 2026
Route path-addressed server function calls solidjs/solid-vite-plugin#332
Merged
2 tasks

frenzzy mentioned this pull request Aug 27, 2026
feat(web): let an app supply the fetch server function calls go through #3080
Merged

github-actionsBot mentioned this pull request Aug 28, 2026
Version Packages (next) solidjs/solid-vite-plugin#331
Merged

github-actionsBot mentioned this pull request Aug 28, 2026
Version Packages (next) solidjs/solid-router#587
Merged

frenzzy mentioned this pull request Aug 29, 2026
A cacheable raw Response is shaped by a request header nothing keys on #3094
Closed