Craft Cloud should not statically cache some actions/controllers e.g. actions/app/health-check

[nottmcollapps]

It looks like static caching gets triggered on the Craft CMS health check endpoint.

https://craftcms.com/knowledge-base/configuring-load-balanced-environments#health-check-endpoint

Because a GET request is used, this gets cached after the first request. Due to the nature and purpose of this action endpoint, I don't think it should be cached at all. It would potentially be something that could be applied within Craft Cloud to basically bypass the actions/app/health-check path from ever being cached,

This endpoint is designed to always return a 200 when OK and an error response, a 304 is not the intended response for it.

[jamesmacwhite]

The health check has been set to have no cache headers in an upcoming release: craftcms/cms#16364

A wider question is the caching of certain action paths generally. I feel there is both good and bad points for doing it.

[timkelty]

Thanks so much James! Caching GETs agnostically (including actions paths) was an intentional decision, but this one definitely should have been excluded.

Given that we forgot this one, it is pretty likely plugins/modules would similar problems, so we are reconsidering.

Thanks again for the heads up!

[jamesmacwhite]

@timkelty No problem. I see the benefit of static caching on action controllers in some contexts I really do, so while @brandonkelly mentioned bypassing it on any actionTrigger path, I don't think it should be a wide exclusion to that level. Certainly for front end controllers that return data from say an element query static caching that is very beneficial and wanted in this case. The problem is if that data is changing regularly or needs to be essentially live, that's where static caching will start causing issues.

Where it works against you, is certain scenarios. For example, we were originally triggering queue jobs via GET requests from a controller and these got caught up in this, basically meaning half the time Cloudflare was just serving a previously run queue job response back and never triggered it. Only when we checked the contents of a Queue::push() and found the same job ID being reported on consecutive execution did it reveal the issue. Switching to POST solves this given all POST requests by default are never cached, so we basically bypass that layer.

I'd imagine there are scenarios where plugins/modules are going to be caught up in the static caching, its GET requests that will cause issues I think.

Switching to POST does usually means disabling CSRF for sending HTTP requests from external services, unless you query the user-session endpoint to send a token or disable CSRF on the controller. You can do it at the action level as well, so you don't have to disable it for all actions under a controller, but this is again additional code to implement. It also becomes a little trickier if you aren't in control of the namespace of the controller, you can use Yii events to override certain properties, but at this point, it is probably better to go to the upstream and just add $this->response->setNoCacheHeaders() into the controller to resolve it.

[jamesmacwhite]

It looks like in the next major Craft CMS release, all action controller requests are going to get the no-cache headers by default. You will be able to override this in controllers if required.

craftcms/cms@a06b1da

This does have an impact on Craft Cloud, where (if released) Craft CMS 4.14 and Craft CMS 5.6 will now be opt-in for action controller caching rather than it being cached by default.

This will have some changes needed for: https://craftcms.com/knowledge-base/cloud-static-caching as since general release, that isn't the default behaviour.

I am inclined to agree that the amount of controllers from plugins and modules, static caching is probably not something considered and may do more harm than good. Being able to opt-in however, is consistent and allows you to still take advantage of it.

This is specifically in actions/controllers, front end web requests remained unaffected.

[jamesmacwhite]

I feel somewhat responsible for opening up pandora's box on this, so I want to make sure that Craft Cloud customers (that includes our organisation) aren't caught out on the next release if it goes ahead with the commit.

I think ultimately, not caching action requests by default is the best move, because I think with the amount of plugins and modules out there, static caching isn't default in Craft CMS itself and not something plugin developers may have considered. Craft Cloud excluding certain action paths from static caching could be an option, but that's committing to maintaining a bypass list, which would have to keep in sync with Craft CMS and possibly would end up having to bypass well used plugins too most likely. The fact that the health-check endpoint was missed (it happens, not major) shows that perhaps that's not really a maintainable option either long term.

The concern I guess is those that are benefiting from the existing default cache behaviour and then if 4.14 and 5.6 releases with that change, completely changes the behaviour the other way around, meaning, adding $this->response->setCacheHeaders() on every controller as needed. Caching action requests is still valid in some contexts, but I think the majority of scenarios, it probably isn't, hence the default no cache headers position.

I did find myself wanting to disable static caching on one of our Craft Cloud environments to make testing easier, while allowing it on others. Ultimately, I settled with using devMode as the main control flag to then send Craft::$app->getResponse()->setNoCacheHeaders() when the request is a site request or action request. As far I know the CP requests aren't ever cached anyway. With the default no cache headers behaviour on actions being proposed by Craft CMS itself, I'd only need to worry about site requests in that scenario and any controllers I specifically want to have cached, but also using devMode (as in when not devMode) as the condition to set cache headers.

The main focus is action requests really, as any site/front-end request is unchanged, POST requests weren't cached, so the documentation probably needs to be updated to mention that Craft Cloud's static cache was originally not selective on any GET request, now it will mostly be for site requests only, unless you opt-in with setting cache headers, either through Twig or a PHP controller.

[timkelty]

As far I know the CP requests aren't ever cached anyway

Correct. Cache headers are only added for site requests.

[jamesmacwhite]

Worth mentioning that since Craft CMS 5.6, caching on 200 GET action requests are now default opt-out and you need to set cache headers explicitly now. Front end/site requests remain unchanged.