-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add filterSerializedResponseHeaders
function
#6569
Conversation
🦋 Changeset detectedLatest commit: 643f664 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
✅ Deploy Preview for kit-demo ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
@@ -143,7 +143,7 @@ export async function load({ depends }) { | |||
- it can be used to make credentialed requests on the server, as it inherits the `cookie` and `authorization` headers for the page request | |||
- it can make relative requests on the server (ordinarily, `fetch` requires a URL with an origin when used in a server context) | |||
- internal requests (e.g. for `+server.js` routes) go direct to the handler function when running on the server, without the overhead of an HTTP call | |||
- during server-side rendering, the response will be captured and inlined into the rendered HTML | |||
- during server-side rendering, the response will be captured and inlined into the rendered HTML. Note that headers will _not_ be serialized, unless explicitly included via [`filterSerializedResponseHeaders`](/docs/hooks#handle) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we not automatically whitelisting any headers anymore? I remember in some version of this proposal, we would automatically include content-type
. That's gone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was whitelisted because some tests expected it, but that seems like a bad reason to keep it. Things like response.json()
work the same way with or without content-type
, so the only time you'd actually need it is if you're explicitly reading that header.
I did wonder about filtering the headers during SSR so that you'd get a 'btw you need to include this header' error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(though now that I think about it i have no idea if it's possible to monkey-patch response.headers
like that)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the monkey has been patched
Co-authored-by: Conduitry <git@chor.date>
Co-authored-by: Conduitry <git@chor.date>
Not forwarding the |
Companion to #6565. Supersedes #6541, closes #1971.
This is a breaking change — it prevents response headers that come from a
fetch
inload
from being serialized into the HTML, unless they are explicitly included.Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. All changesets should bepatch
until SvelteKit 1.0