Describe the problem
If I have a +server.js endpoint that ends in a return fetch(...), this works fine in development, but if during building I attempt to prerender this endpoint's response, I get an error about headers being immutable from within undici. Presumably, SvelteKit is trying to change the response headers that it's getting from the +server.js function, and presumably the Response object that undici returns has had its headers frozen.
Describe the proposed solution
I think SvelteKit, at least when prerendering, should attempt to create a new Response object when it's adding its headers to the response.
Part of me has the potentially bad idea of running all undici responses through the code listed below in 'Alternatives considered'. Presumably someone, if they attempted to mutate such a Response in their handle hook after calling resolve would run into this same issue, even when not prerendering. (I've not actually tested this.) But perhaps at that point it's their responsibility to make sure they're handling this appropriately?
Alternatives considered
Right now, I'm running the responses through
new Response(response.body, {
status: response.status,
statusText: response.statusText,
headers: new Headers(response.headers),
})at the bottom of each relevant GET function, which works fine, but it took me a while to figure out what was going on and to arrive at this as a solution.
Importance
nice to have
Additional Information
No response
Describe the problem
If I have a
+server.jsendpoint that ends in areturn fetch(...), this works fine in development, but if during building I attempt to prerender this endpoint's response, I get an error about headers being immutable from within undici. Presumably, SvelteKit is trying to change the response headers that it's getting from the+server.jsfunction, and presumably theResponseobject that undici returns has had its headers frozen.Describe the proposed solution
I think SvelteKit, at least when prerendering, should attempt to create a new
Responseobject when it's adding its headers to the response.Part of me has the potentially bad idea of running all undici responses through the code listed below in 'Alternatives considered'. Presumably someone, if they attempted to mutate such a
Responsein theirhandlehook after callingresolvewould run into this same issue, even when not prerendering. (I've not actually tested this.) But perhaps at that point it's their responsibility to make sure they're handling this appropriately?Alternatives considered
Right now, I'm running the responses through
at the bottom of each relevant
GETfunction, which works fine, but it took me a while to figure out what was going on and to arrive at this as a solution.Importance
nice to have
Additional Information
No response