Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SvelteKit demo app not working #39

Open
peterlerche opened this issue Nov 10, 2023 · 3 comments
Open

SvelteKit demo app not working #39

peterlerche opened this issue Nov 10, 2023 · 3 comments

Comments

@peterlerche
Copy link

Desperate to find a solution to #38 I made a clean installation of Svelte demo app using the guide on https://bun.sh/guides/ecosystem/sveltekit.

When browsing the demo app, I get a lot of the below faults.

709 | });
710 | };
711 | var get_origin = function(headers) {
712 | const protocol = protocol_header && headers.get(protocol_header) || "https";
713 |
714 | const host = headers.get(host_header);
^
TypeError: Invalid header name: ''
at get_origin (/my-app/build/index.js:714:15)
at ssr (/my-app/build/index.js:682:23)

Why do we see these faults, is Bun changing their internals or is svelte-adapter-bun out of sync with the newer version of bun?

All help, ideas, and guidance will be appreciated.

@Dan1ve
Copy link

Dan1ve commented Nov 11, 2023

I have the same problem in a "real" application, not just the demo.

@Dan1ve
Copy link

Dan1ve commented Nov 11, 2023

Until this has been merged, it seems a fix is to set the following env variables:

PROTOCOL_HEADER=x-forwarded-proto
HOST_HEADER=x-forwarded-host

@chevcast
Copy link

chevcast commented Nov 24, 2023

I've forked this repo and published my own NPM package. The fix for this issue is already merged into my fork and I plan to keep it updated. Anyone else having this issue is free to use it if you'd like:

bun add @catdadcode/svelte-adapter-bun -D

https://github.com/catdadcode/svelte-adapter-bun

I've also added signal event handling to the fork. Previously if you ran your Svelte app in a Docker container then killing the container would take 10+ seconds before Docker would force kill it. The resulting build/ app from this adapter now has proper process signal handling and will gracefully shutdown immediately upon receiving any of SIGTERM, SIGINT, SIGQUIT, SIGSTOP, or SIGKILL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants