Missing headers in request only in netlify (sveltekit)


I’m creating a new SvelteKit app deployed in netlify (using @sveltejs/adapter-netlify).
Sveltekit has a feature call hooks, which this adapter basically converts into netlify functions.

In the app I’m setting a cookie for the user preferred locale that I want to read from the hook (netlify function) and use it so when the app server-side renders it does it in the right language so it doesn’t re-renders on a different language when javascript kicks in.

I’ve noticed that my request object in the hooks doesn’t have any headers. None. Running the app locally it works fine, and I’ve verified that I am indeed sending headers, so I can only assume netlify is stripping them.
How can I ensure I receive headers? How can I even be sure wether netlify is to blame and not the adapter (although again, it works well locally).

For completeness, my netlify.toml file is this:

  command = "npm run build"
  publish = "build"
 command = "svelte-kit dev"
  directory = "netlify/functions"
  node_bundler = "esbuild"

Hi @cibernox,

Could we see the site in question?

Absolutely, you can even see the source code as it’s open source:

Hi @cibernox,

I can see the cookies being sent:

However, it’s the function that fails to render correct content based on cookie. This can also be verified by:

curl --cookie "lang=es" https://svelte-intl-precompile.com/ and you can see, it returns the English page.

I am well aware of that. And the reason why the function renders it in english instead of the language being set on the cookie is because the cookie never makes it into the function. If I inspect the request received by the function it has no headers from where to read the cookie.

What what I want to know. Why I don’t receive headers in my function.

How are you inspecting this? I just checked your function logs and don’t see any relevant data.

If what you’re saying is true, I’d believe this is because of proxying - we might be dropping cookies during proxying, but I’d want to test their theory to confirm, which is why I asked if you’re logging something in your functions.

I couldn’t see in the logs anything either, so I deployed this to prod since I’m the only one visiting this page for now: My last idea · cibernox/svelte-intl-precompile-docs@967bd7e · GitHub

Then I inspected in the browser what the entire get request looks like, and got this:

As you see it has no headers at all. Now, I don’t know if this is netlify doing the redirection or something wrong in sveltekit’s netlify adapter, but it does work when running the app locally.

The reason why I asked you to add the logs to your function is so that we can directly hit the function endpoint with the cookie and see if the cookie gets logged there. If it does, then Netlify is indeed stripping out the cookies (I believe it does) and it could be for the better.

This is because, using 200 rewrites, you could proxy to any site and by sending cookies along with the request you could possibly leak secret information from a website. So, I’d assume that’s why it’s happening, but if you wish to confirm, you could log the event in Functions’ logs, and send the cookie with cURL and see what happens.

I added a console.log now.
It’s weird, I can see some logs, but for paths like /site/wp-includes/wlwmanifest.xml and others I don’t recognize, but making requests with curl (like you pasted above) or actually browsing the page doesn’t show in the log.
However I am certain the function is being executed because as you saw in the image above, my session contains an acceptedLanguage with the information I set on that function.

I didn’t fully understand what the security concern might be. What rewrite is being done? Cookies are a fundamental piece of the internet, so it seems rather surprising one can’t deploy in netlify an app that uses cookies.

Interesting, I’m not seeing any logs for any paths.

Could you point me to to the file in which you used the log statement?

The adapter that you’re using, adds a rewrite rule which sends any page of your website to the serverless function to render. A similar rule could be used to trick browsers into allowing CORS as for the browser, the domain remains the same, but the response is received from the external resource instead of the actual URL you’re hitting. So, for example, I could show google.com on my example.com website using rewrite rules. For the browser, the URL would seem example.com, but the content would actually come from google.com. So, in this case, if I setup cookie for example.com and they get forwarded with the request, you could potentially access google.com with the ‘hijacked’ cookies.