Massive link headers causing site failures #6519
Replies: 5 comments 11 replies
-
|
I ran into the same issue and @kevinrenskers solution of adding those options to the top line of my 443 server block worked for me too. I'm on version 1.0.0-next.465 and use the node-adapter. I have a route that uses a slug that couldn't be reloaded in production, but could be navigated to from parent directory via client-side nav. When reloading the slug page, the 502 would show up and you'd have to push back on the browser and then refresh again to get the site working. I found the exact same error as above in my NGINX logs. |
Beta Was this translation helpful? Give feedback.
-
|
Can you see if setting this option helps: #2612 (comment) If it doesn't, would it be possible to share your code? I'm curious why your page would be using so many JS files |
Beta Was this translation helpful? Give feedback.
-
|
I can't share my code. But if you fetch https://www.critical-notes.com/campaigns/130/characters/4955 using something like Paw or Postman or just curl, you can see the link header:
I'm a bit afraid of using an experimental option in my production site, and don't have time to set up a staging server. |
Beta Was this translation helpful? Give feedback.
-
|
I'm far less optimistic the option will really help now having seen the header. That being said, you could easily test the option locally. You might not know if it solved this issue without putting nginx in front of it, but you could pretty easily see that it's not going to break anything. We're about to turn it on for everyone and make it not experimental. The only real issue we need to fix first is that if you change Svelte compiler options during dev mode it won't pick that up, but it should be pretty safe to use in production. We could offer some type of option to disable or reduce the link header, but I think we're much better off trying to reduce the number of JS files being loaded. The link header tells the browser that this is all the JS you will need for the page so it can get to work loading it as soon as possible. Disabling the option will make your site slower especially since there are so many JS files to load. There are a couple things I noticed. One is that it sort of looks like you might have five layouts being used on the page? It's hard to tell just from the compiled code without seeing the source, but there's really a lot of layout-related files and I'd like to understand what's going on there. The other thing is that every menu item seems to have its own Svelte component. It'd probably help to refactor that such that there's just a generic MenuRow.svelte. I also wonder if there's something Vite could do to bundle these together into a single file as I'm assuming they're always used together |
Beta Was this translation helpful? Give feedback.
-
There are 4 layouts involved here. The character detail page is slotted into the characters list layout so you have the list of characters on the left, and then the details
No, the characters page shows linked quests, locations and factions, which all have their own component.
Considering Svelte works best when stuff is broken up into components.. yeah there are a bunch of them on the page.
Agreed. I'm actually kinda surprised all these little JS and CSS are not bundled. |
Beta Was this translation helpful? Give feedback.
-
|
I'm also using nested layouts, but just 2. With this structure, |
Beta Was this translation helpful? Give feedback.
-
|
This should be reported as an issue ? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Per #6790 (comment), this is easy to fix in a export function handle({ event, resolve }) {
const response = await resolve(event);
response.headers.delete('link');
return response;
} |
Beta Was this translation helpful? Give feedback.
-
|
What about if we want to get rid of the link headers, but still revert to the previous behavior of having |
Beta Was this translation helpful? Give feedback.
-
|
where does this handle function go? Which file? |
Beta Was this translation helpful? Give feedback.
-
|
It should go into hooks.server.js (or .ts) |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, we had to increase the proxy buffer in our NGINX config in order to fix this issue, since link header becomes quite too long. We also saw that preload links are also represented in the form of HTML tags inside the element. |
Beta Was this translation helpful? Give feedback.
-
|
Ever figured your last question out? Are they necessary? :) |
Beta Was this translation helpful? Give feedback.
-
|
Not sure. Probably SvelteKit relies on it internally in some way I presume |
Beta Was this translation helpful? Give feedback.
-
|
I presume it's cache related? |
Beta Was this translation helpful? Give feedback.
-
Today I ran into a really strange issue: when I opened https://www.critical-notes.com/campaigns/130/characters/4955 I got an error 502 Bad Gateway page from Nginx, but I was able to load https://www.critical-notes.com/campaigns/130/characters just fine, and navigate to a character. But I couldn't reload, or I would get the 502 again.
After some searching I found out that the link header is so big that nginx just refuses to deal with it:
2022/09/01 22:36:39 [error] 3352048#3352048: *4228330 upstream sent too big header while reading response header from upstream, client: 35.237.4.214, server: www.critical-notes.com, request: "GET /campaigns/130/characters/4955 HTTP/1.1", upstream: "http://127.0.0.1:3000/campaigns/130/characters/4955", host: "www.critical-notes.com"And looking at the header, there are a LOT of JS files in there, it's really rather big.
I did managed to solve it by adding this to my nginx site config:
But is this to be expected? What's that link header doing, does it need to be so big? Is this documented somewhere? And in general, is there any documentation on hosting this yourself? I am currently using adapter-node and nginx and it works (until it doesn't). Would love to get some official docs on this.
Beta Was this translation helpful? Give feedback.
All reactions