Set no-cache headers for health check endpoint

[jamesmacwhite]

Description

Currently with static caching in use, the health check endpoint response can be cached when using GET and return a 304 response by a client. This occurs on Craft Cloud, but possible also with other static caching solutions i.e. Blitz.

This sets $this->response->setNoCacheHeaders(); in the action controller to prevent this from happening.

[brandonkelly]

Thanks for the PR! I’ve cherry-picked it for the upcoming 4.14 and 5.6 releases (ae59346).

I’ve also brought this up with the Cloud team – we probably should not ever be statically caching URIs that begin with actions/ (or whatever the actionTrigger is set to).

[jamesmacwhite]

@brandonkelly Thanks!

I did add a discussion on the Craft Cloud GitHub as well about it for reference: craftcms/cloud#54, I raised it here as ultimately it probably needs enforcing regardless, given the health check endpoint needs to always test the Craft CMS application readiness state and should never be a cached result.

I think certainly certain actions shouldn't ever be cached, but there is some benefit to static caching for front end controllers, particularly if they serve large data i.e. from an element query or similar. E.g. a current use case of ours we generate an XML response through a controller rather than Twig, this gets statically cached and because it involves a decent amount of entries and fields, this is a good thing, even with eager loading, it is wasteful running that query each time.

When you have direct access to the controller you can of course set the no cache headers yourself when dealing with GET requests, the issue is other controllers outside of your namespace, which you can technically influence through Yii events still, or switch to POST requests which are never statically cached, but then you'd have to get a CSRF token each time or turn it off, which again you can do through Yii events (if not your controller namespace), but yeah I guess certain action paths should never be cached.

Thanks for cherry-picking the PR!

[brandonkelly]

I went ahead and made all action requests get no-cache headers by default, because in general I think that‘s probably the expected behavior. Individual controllers/actions can override that behavior though, via $this->response->setCacheHeaders().

[jamesmacwhite]

Opting in is probably the safest across all the various scenarios.

It might be worth discussing internally with the Craft Cloud team because it will remove some automatic caching happening in places. The documentation about static caching will need amending for the next Craft CMS 4 and 5 releases around the switch to opting in.

https://craftcms.com/knowledge-base/cloud-static-caching

[brandonkelly]

Craft 4.14.0 and 5.6.0 is out with that change.