Cache control directives stale-while-revalidate and stale-if-error for frontend do not get sent even when Ghost config is set

[JamesMarino]

Issue Summary

Cache control directive stale-while-revalidate and stale-if-error for frontend do not get sent as header directives even when passed in configuration values for caching.frontend.staleWhileRevalidate and caching.frontend.staleIfError.

Please note code has not been allowed specifically for staleIfError cache control directive config but should be included due to its usage in conjunction with staleWhileRevalidate. Please see MDN docs here on Cache-Control for further information.

Initial changes have been made here it seems #15734 and I can submit a fix shortly as a PR.

Also, documentation has also not been updated for caching, whereabouts can changes to documentation be submitted?

Steps to Reproduce

1. Initial Setup of the Ghost site locally

yarn setup

2. Run the site with a custom maxAge to ensure environment variables are being passed through and with a custom staleWhileRevalidate value to show that this directive is not being received in the Cache-Control header

export caching__frontend__maxAge=1800
export caching__frontend__staleWhileRevalidate=604800
yarn dev

3. Send off a request to the home page and initial post to show it's not being sent

curl -s -i http://localhost:2368/ | grep -i "Cache-Control"

# Output:
# Cache-Control: public, max-age=1800

4. Try another post page as well

curl -s -i http://localhost:2368/coming-soon/ | grep -i "Cache-Control"

# Output:
# Cache-Control: public, max-age=1800

Ghost Version

v5.105.0

Node.js Version

v18.20.4

How did you install Ghost?

Local Development on MacOS 15.1.1

Database type

MySQL 5.7

Browser & OS version

No response

Relevant log / error output

No response

Code of Conduct

• I agree to be friendly and polite to people in this repository

[ErisDS]

Hello @JamesMarino 👋
At first glance this does appear to be a bug, and the PR looks good - thanks for writing tests 🥰

I need to do a bit of internal fact checking to determine what the reason for adding this was, and be sure there’s no major dependency on this bug somewhere. Not gonna get to that before the holidays now.

I wondered if you could share a bit more about what’s behind these changes and in particular if it’s likely you’ll be brining more cache related changes, as it’ll be easier to handle them in a batch :)

[JamesMarino]

No worries @ErisDS - thanks for the feedback.

I thought it would be a good idea to bring the caching config inline with the Cache-Control HTTP spec which seems to be implemented and respected by various CDN providers.

This was mostly all the caching changes that I was planning to bring in unless configuration keys other than frontend such as contentAPI or publicAssets were to be updated with stale-while-revalidate and stale-if-error cache directives as well. Other cache directives could be introduced as configurable parameters but if there no demand from the community for more cache directives this could be left as is for now.