paoloricciuti
commented
5 months ago I faced the same problem some times ago and from my research is not an issue with sveltekit. The problem should be that the moment you fetch something in node it will be decoded with the Content-Encoding regardless if you access the body or not.
So the response that you are returning to the browser is not exactly the same request, because node already decoded the body. But since the Content-Encoding header is still set the browser will try to decode with the wrong decoder.
A better solution then this
export async function GET() {
const resp = await fetch('https://en.wikipedia.org/wiki/Main_Page');
const t = await resp.text();
return new Response(t);
}should be this
export async function GET() {
const resp = await fetch('https://en.wikipedia.org/wiki/Main_Page');
// copy the response headers over
const headers = new Headers(response.headers);
// delete content-encoding.
headers.delete('content-encoding');
return new Response(response.body, {
headers,
status: response.status,
statusText: response.statusText,
});
}
clement-fischer
kentonv
Simre1
Describe the bug
With 3rd party cookies soon to be blocked for authentication with Firebase, I was trying to create a hook to proxy the requests to Firebase as described here. It's simple to implement, but it leads to errors on the client side (Chrome in my case). Looking at the Network tab in Chrome Dev Tools shows an error in the "Status" column:
(failed)net::ERR_CONTENT_DECODING_FAILED.I added some debugging info to understand the problem and found a mismatch between the size of the request as reported by Chrome Dev Tools vs the
Content-Lengthheader in the response to the proxied request.I think that what is happening is Sveltekit returns the HTTP response body as-is (compressed with gzip), but does not return the associated
Content-Encoding: gzipheader. Sveltekit does not pass any of the headers from the proxied response Perhaps this is intentional, but I think this is what's causing this issue.The workaround is to decode the response and create a new one, but this is a little annoying to do because some of the headers may need to be added back. For example in the case of Firebase, the workaround would not work until the 'Content-Type' header was added, the Firebase library could would reject the response without it (no reported error, making it difficult to understand). And it is slower too.
It might be worth to add that I wish there was a better way to proxy these requests instead of doing it in code. I know there is a way with the Vercel adapter using
rewrites, and in local development vite can do it, but there is no such feature with node-adapter. If node-adapter had such a feature, I think it'd be more convenient than proxying with a hook. That could be a feature request ticket, but I think the issue described above is a bug.Reproduction
In any Sveltekit app, add a
/wikiroute with the following code:When using the code as is, the error will show in the status column of the network tab in Chrome Dev Tools. Using the commented out code works and the raw HTML will show on the page.
Logs
No response
System Info
Severity
serious, but I can work around it
Additional Information
No response