Skip to content
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

Merged
merged 6 commits into from
May 2, 2023
Merged

fix: respect response status code for caching in adapter-cloudflare #9768

merged 6 commits into from
May 2, 2023

Conversation

psytrx
Copy link
Contributor

@psytrx psytrx commented Apr 25, 2023

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:

  • 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 test and lint the project with pnpm lint and pnpm check

Changesets

  • If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

@changeset-bot
Copy link

changeset-bot bot commented Apr 25, 2023

⚠️ No Changeset found

Latest commit: 05e9488

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@psytrx
Copy link
Contributor Author

psytrx commented Apr 25, 2023

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 pragma and res are being re-used for different requests. Same for is_static_asset. I enjoy consts, which would allow for some cleanup/extraction and an easier to grasp fetch handler. So rather a general question: Are refactors welcome as PRs?

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;
Copy link
Member

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

Copy link
Contributor Author

@psytrx psytrx Apr 26, 2023

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.

Copy link
Contributor Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Contributor

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.

Copy link
Contributor Author

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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return !is_error(res.status) ? Cache.save(req, res, context) : res;
return res.status >= 400 ? res : Cache.save(req, res, context);

Copy link
Member

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

Copy link
Contributor Author

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?

@eltigerchino
Copy link
Member

@fjdumont thanks for the PR! Are you happy with the current state of the PR before I merge?

@psytrx
Copy link
Contributor Author

psytrx commented May 2, 2023

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).

@eltigerchino eltigerchino merged commit 696ab68 into sveltejs:master May 2, 2023
@eltigerchino eltigerchino changed the title adapter-cloudflare: respect response status code for caching fix: respect response status code for caching in adapter-cloudflare May 2, 2023
@eltigerchino
Copy link
Member

eltigerchino commented May 2, 2023

I'm an idiot and forgot to make sure there was a changeset before merging.

Do we need a changeset? Is changing cache behavior considered backwards compatible?

I think so, just as a patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants