Use parent request headers in server-side fetch
#2911
fetchClosing issue
Fetch call made from the server should have the same headers, as the one made from the client.
<!-- index.svelte -->
<script context="module">
export async function load({ fetch }) {
const { headers } = await fetch('/content.json').then(res => res.json())
return {
props: { headers }
}
};
</script>
// content.json.ts
export const get = (request) => ({
body: {
headers: request.headers // <- headers: {} if requested during SSR, but populated otherwise
}
});
In the above case the request.headers are empty ({}) if requested during SSR, but populated when requested from the client on navigation or if requested directly.
The expected behavior is that in both cases the headers are populated and requests look the same.
envinfo:
npmPackages:
@sveltejs/adapter-node: next => 1.0.0-next.10
@sveltejs/kit: next => 1.0.0-next.60
svelte: ^3.29.0 => 3.35.0 Pull request
Fixes: #696
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
- It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
- This message body should clearly illustrate what problems it solves.
- Ideally, include a test that fails without this PR but passes with it.
Tests
- Run the tests with
pnpm testand lint the project withpnpm lintandpnpm check
Changesets
- If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running
pnpx changesetand following the prompts. All changesets should bepatchuntil SvelteKit 1.0
Info
🦋 Changeset detected
Latest commit: 976c62e
The changes in this PR will be included in the next version bump.
This PR includes changesets to release 1 package
| Name | Type |
|---|---|
| @sveltejs/kit | Patch |
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
Thank you — closing in favour of #3631, which is more current
Pro tip: You can prefix GitHub URLs of issues, PRs or discussions with svcl.dev/ to view them on this page! Also try it on a GitHub release ;)