chore: derive content-length from fixed response bodies in setResponse

[Nic-Polumeyv]

On Node, setResponse streams every response.body through a reader loop, so a response without a pre-computed content-length header is served with chunked transfer encoding. That is why the runtime can't move off the deprecated json/text helpers, whose only load-bearing job is stamping that header, and why a plain Response.json returned from an endpoint is served chunked today. Every other runtime derives the header from fixed bodies at serve time.

setResponse now races the body's first reads against a setImmediate deadline before writing the head. A fixed body settles value-then-done on microtasks, so it is sent with a measured content-length; a body that leaves a read pending is a genuine stream and goes through the existing streaming path unchanged, with its headers delayed by at most one tick. Nothing is added when the response already carries a content-length or a transfer-encoding (proxied responses can carry the latter, and the pair would be invalid). Same approach as hono's node-server.

json/text are untouched. Retiring them internally becomes a follow-up; its one catch is the http.response.body.size span attribute, which reads the content-length header.

#16804 is stacked on this.

[pkg-svelte-dev]

Install the latest version of @sveltejs/kit from 44c0e5f:

pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/44c0e5f63073bf257f37c9c4b540be6bff19ab66

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/kit/pr/16794

[changeset-bot]

🦋 Changeset detected

Latest commit: 44c0e5f

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

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	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

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-kit-16794-svelte.vercel.app/

[WolfieLeader]

Noice, do you think it should be updated in other parts as well? also would the json from sveltekit would be deprecated from the develop side as well? if so what about using the json as an alias to Response.json?

[teemingc]

I think for that exact reason you've mentioned (no content-length headers) we've avoided switching away from it for now.

[ottomated]

It seems a bit complicated for something that no longer gets rid of the need for json() and instead is only really an optimization (have you benchmarked it)?

[Nic-Polumeyv]

You're right. I think there is a better redesign here. wip

[WolfieLeader]

Lol didn't mean to make you doing a redesign😅

[Nic-Polumeyv]

Yeah, I wasn't trying to do one either, unfortunately node has to always be in the way. A redesign was necessary to make this PR appealing.

[Nic-Polumeyv]

@ottomated I benchmarked this rework with autocannon, setResponse in isolation.

small JSON ~30k req/s on both, 20KB bodies ~300 vs ~430 MB/s, 5MB bodies ~1GB/s on both. So yes, more performant: ~40% more throughput on page-sized responses, parity everywhere else!

[Rich-Harris]

it's a shame that this adds some complexity but i don't see a simpler alternative