SvelteKit on Fly.io: Problem with finding out the correct origin from the request url when ORIGIN is set as an envvar

[mql]

The problem is best described with an example.

// TEST CASE 1 (Deployment on Fly.io)
// 
// ORIGIN=https://mydomain.com

// hooks.server.js when requesting https://www.mydomain.com
export async function handle({ event, resolve }) {
  console.log('request origin', event.url.origin); // prints https://mydomain.com which is WRONG
  const response = await resolve(event);
  return response;
}

// TEST CASE 2 (same deployment on Fly.io ...
// but without the env var set)

// hooks.server.js when requesting https://www.mydomain.com
export async function handle({ event, resolve }) {
  console.log('request origin', event.url.origin); // prints https://www.mydomain.com which is CORRECT
  const response = await resolve(event);
  return response;
}

I really wonder why this is the case. When testing locally for instance everything works as expected (e.g. when I access http://localhost:5173 vs http://192.168.0.4:5173).

I’m unsure if this problem can be traced down to SvelteKit or to Fly.io, but I wanted to ask here, maybe someone has an idea.

This Twitter thread has some more context:

Michael Aufreiter

And here’s some possibly relevant bits from the SvelteKit documentation:

Node servers • Docs • SvelteKit

Thank you for your help,
Michael

[mql]

Update: I figured that also the raw event.request.url is available too, so I looked into that. But it has the same behavior. The start of the request url gets locked into whatever has been provided for ORIGIN=.

[keybits]

I believe the issue is that Fly doesn’t forward X-Forwarded-Host as it’s not listed in the docs: Public Network Services · Fly Docs

Even if they did I’m not sure it can be trusted as the X-Forwarded-xxx headers are open to spoofing.

Is there a reliable way to get the host or hostname for an app running on Fly?