Bad Request Errors After Upgrading to @sveltejs/kit@2.30.0 and @sveltejs/adapter-node@5.2.15

[abdelfattahradwan]

Describe the bug

All of our production apps started returning Bad Request when accessing any routes after upgrading to @sveltejs/kit@2.30.0 and @sveltejs/adapter-node@5.2.15.

Reproduction

• Create a new SvelteKit project.
• Update to the latest SvelteKit version.
• Install the latest version of adapter/node.
• Build & deploy your application.
• Navigate to any route in your application.

Logs

N/A

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (28) x64 Intel(R) Core(TM) i7-14700K
    Memory: 32.65 GB / 63.70 GB
  Binaries:
    Node: 22.18.0 - C:\Program Files\nodejs\node.EXE
    npm: 11.5.2 - ~\AppData\Roaming\npm\npm.CMD
    bun: 1.2.20 - ~\.bun\bin\bun.EXE
  Browsers:
    Edge: Chromium (139.0.3405.86)
    Internet Explorer: 11.0.26100.1882
  npmPackages:
    @sveltejs/adapter-node: 5.2.14 => 5.2.14 
    @sveltejs/kit: 2.29.1 => 2.29.1 
    @sveltejs/vite-plugin-svelte: ^6.1.2 => 6.1.2 
    svelte: ^5.38.1 => 5.38.1 
    vite: ^7.1.2 => 7.1.2

Severity

blocking all usage of SvelteKit

Additional Information

The affected apps are deployed on bare-metal servers behind Cloudflare, acting as a proxy.

[stevenklar]

+1, this also broke our app
we have envoy as proxy, pretty similiar to what CF does, so I suspect the HOST_HEADER change is the issue here.
#11154

Is there a way to circumvent the change/fix in adapater-node/5.2.14?

EDIT: Locally it works fine in development mode.

[Conduitry]

Yup, I can confirm this in my own app, which is also deployed behind Envoy. I haven't sorted out where the error is coming from yet. I would suggest downgrading adapter-node in the meantime.

[abdelfattahradwan]

Yup, I can confirm this in my own app, which is also deployed behind Envoy. I haven't sorted out where the error is coming from yet. I would suggest downgrading adapter-node in the meantime.

I downgraded to the earlier version, and things are working OK for now.

[stevenklar]

After trying to understand the actual issue a bit, I think this happened:

• (host_header && headers[host_header]) evaluates to '' when host_header is an empty string.
• '' ?? headers['host'] does not fall back (because ?? only falls back on null/undefined, not on '').

Same story for protocol: if PROTOCOL_HEADER isn’t set, the expression becomes '' ?? 'https' → ''.

tl;dr - I guess the result behind proxy might be :// when the env vars are not set.

[Conduitry]

Opened #14221.

[Conduitry]

This should be good now in v5.2.16 of the adapter.