-
-
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
fix: respect response status code for caching in adapter-cloudflare
#9768
Conversation
|
As asked in #9721, is this as straightforward as it seems? What do I miss? Also, is this a minor bump? It should gracefully fall back to responses from the origin, but changing cache behavior can have a significant impact on some. Some less relevant thoughts on worker.js: I found it a bit confusing that |
return pragma && res.ok ? Cache.save(req, res, context) : res; | ||
|
||
// only save good responses to Cache | ||
return should_cache(res) ? Cache.save(req, res, context) : res; |
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.
This should just be a statusCode check, leaving Cache.save
to employ the rest of the "is this cacheable" logic
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.
Thanks! You're right, Cache.save
already looks into the cache-control
(and also the vary
) header, which makes should_cache
redundant. I'll revert to the simple is_error
check as seen in adapter-cloudflare-workers.
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.
This means I can also remove the pragma && res.ok
condition, correct? Because the response will not be ok
if status > 399
, and Worktop makes sure it respects the headers.
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.
Yes
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.
@lukeed I have looked into Cache.save
and found out that it didn't handle the case when cache-control
is empty and let it cache by default. So every dynamic content without cc will cache by default in case of performance it's good but I'm curious about security as I describe in this issue lukeed/worktop#176.
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.
Can confirm. The check for a cache-control
header got lost in this PR.
I'll create an issue and propose a fix.
return pragma && res.ok ? Cache.save(req, res, context) : res; | ||
// write to `Cache` only if response is not an error, | ||
// let `Cache.save` handle the Cache-Control and Vary headers | ||
return !is_error(res.status) ? Cache.save(req, res, context) : res; |
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.
return !is_error(res.status) ? Cache.save(req, res, context) : res; | |
return res.status >= 400 ? res : Cache.save(req, res, context); |
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.
And remove the other lines. I can’t do multi line on phone
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.
Thanks! Done. Remove or revert the comment as well?
@fjdumont thanks for the PR! Are you happy with the current state of the PR before I merge? |
Do we need a changeset? Is changing cache behavior considered backwards compatible? Otherwise, it looks good to me, thanks for asking. There's some bits and bobs I'd like to improve in the worker.js, but I'll consider opening a new PR to get this one merged (see my comment above). |
adapter-cloudflare
I'm an idiot and forgot to make sure there was a changeset before merging.
I think so, just as a patch. |
This aims to solve #9721 .
Currently, adapter-cloudflare does not respect the status code of internal requests for caching.
This is behavior is different to how adapter-cloudflare-workers and adapter-node behave.
This PR extends the cache-check to behave similarly.
This will also help with out-of-sync cache misses during deployments (outdated edge nodes receive a request from the freshly deployed app version, respond with 404s, DNS caches the bad response). This affects thousands of my users on each deployment. Rapid build, test and deploy cycles is one of the reasons I chose SvelteKit.
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. Changesets that add features should beminor
and those that fix bugs should bepatch
. Please prefix changeset messages withfeat:
,fix:
, orchore:
.