Potential pitfall around filterSerializedResponseHeaders

[Nickersoft]

Hey SK folks,

Just wanted to start a discussion regarding the filterSerializedResponseHeaders option, as I just spent the better part of the last week trying to chase down why my code wasn't working 😅 Like many other devs, I've been using URQL to call GraphQL in my app, and have quite a few server-side queries I use to pre-render pages. Something I didn't realize, however, is that with most GraphQL clients, receiving anything from the server that isn't of content-type application/json is interpreted as an error by the client. By default, SvelteKit doesn't serialize any headers during SSR, which causes the rehydration of my GraphQL queries to have content-type text/plain (the default content type of new Response()) and leads to a crash of my page.

It wasn't until I added breakpoints throughout SvelteKit's fetch implementation that I realized what was going on and stumbled across filterSerializedResponseHeaders. Using this option to whitelist content-type in my handle() method naturally fixed my issue.

However, given the plethora of devs who use GraphQL, I can't help but feel this could be a potential pitfall for newcomers to SvelteKit. I wanted to start this thread for a couple of reasons:

1. I haven't been following all of the implementation decisions in this repo suuuuper closely, so I'm curious if anyone from the SK team could shed some light on the decision to not serialize all response headers (or at least some important ones). Is it just to save on the amount of data rendered in the script tag on page load?
2. What do people feel could be a good way to rectify this? Should a collection of certain headers be serialized by default? Should I open an issue over on the URQL repo to add documentation that serializing content-type should be required by SvelteKit apps?

I know a lot of folks have said that the SK docs should be improved, and I also know that there's already been some confusion regarding getting empty response headers on page rehydration. So I'm curious how everyone feels about all this.

Thanks! Looking forward to 1.0 🚀

[navtoj]

@Nickersoft How did you set up filterSerializedResponseHeaders in SvelteKit?

[navtoj]

I'm using the below code in hooks.server.ts. On the first page load, the server-side fetch response has all the headers. However, only content-type is returned on subsequent client-side fetch requests.

import type { Handle } from '@sveltejs/kit';

export const handle = (async ({ event, resolve }) => {
    return resolve(event, {
        filterSerializedResponseHeaders: () => true // basically get all headers
    });
}) satisfies Handle;

First Page Load

{
    "access-control-allow-origin": "https://localhost:5173",
    "content-encoding": "gzip",
    "content-type": "application/json; charset=UTF-8",
    "date": "Fri, 03 Feb 2023 04:48:55 GMT",
    "etag": "\"6cf4c5a42d51741ba6547911ca68ebdac3516dfc\"",
    "server": "deno/gcp-us-west1",
    "transfer-encoding": "chunked",
    "vary": "Accept-Encoding, Origin",
    "via": "http/1.1 edgeproxy"
}

Subsequent Requests

{
    "content-type": "application/json; charset=UTF-8"
}

[navtoj]

I read through #7112, #8262, #6750, etc. but couldn't find any solution.

[half2me]

I'm having this exact issue with urql, but even after setting the option, its still not working for me. I already use a third party handle function (Next.js auth), so I tried using the sequence() helper to run them both. However, it seems like if you use sequence it breaks it, as it does not respect filterSerializedResponseHeaders

Look at this example handle function

const myHandle: Handle = async ({ event, resolve }) => {
  return await resolve(event, {
    filterSerializedResponseHeaders: (name) => {
      console.log(name) // so we can see if it even gets called
      return true
    },
  })
}

This works perfectly:

export const handle = myHandle

This fails, as all the headers get omitted:

export const handle = sequence(myHandle)

This is quite annoying as I really need to use another handle function :/

[half2me]

yeah, so this is referenced here: #8061 (comment)

[smart]

Trying to implement a fetch call to a paginated api that uses headers Total, Per-Page, I setup the filterSerializedResponseHeaders to work on serverside calls, but the clientside load calls do not get the headers back.

[half2me]

@smart are you using the sequence() helper? In my case that striped the option completely.

[smart]

I discovered that my issue comes from the client side calls being CORS, which strips all the headers other than content-type, so I don't think there is a bug here, just a confusion issue.

[guldmytro]

I had the same problem with my response headers in page load function.
Try to rename your +page.js file to +page.server.js It helped me to get headers on a client and server side.
Hope it'll help)