Comment by AlienRobot
3 days ago
They can't do that because a CMS under Cloudflare needs to be configured to bust the Cloudflare cache when content is edited or the user will see cached content after they edit a page.
3 days ago
They can't do that because a CMS under Cloudflare needs to be configured to bust the Cloudflare cache when content is edited or the user will see cached content after they edit a page.
That might be the default configuration if your CMS doesn't return any cache-control headers. But Cloudflare definitely [0] supports must-revalidate and etag or last-modified, which is also probably supported by whatever CMS you're using. HTTP conditional requests are very old and very widely supported.
[0] Okay, my claim is only definite up to my memory of using Cloudflare for a fairly high-traffic circa 2019-2022. I haven't used Cloudflare after that point, but a quick search of their docs shows support
Right. But if the cache MUST be revalidated every time, it's the same thing as being disabled.
The point of a reverse proxy is to reduce load on the server rendering the page. If you GET, the page is rendered. So in order for etag/last-modified to be effective, the CMS must implement HEAD. If the CMS doesn't implement HEAD or implements it in a way that ends up doing all the work of GET anyway, you just end up with more load than just doing a GET every time.
The funny thing is that the way HTTP is designed the simplest PHP script can do this correctly, because the server must send the headers first, so a PHP script can NOT do the work to generate the HTML until it has sent the correct headers, as they won't be able to change the headers after they start sending the body. In theory, the process could just shut down the instant the first body byte starts being sent and save work in a HEAD request. The problem is that pretty much everything works in a more "clever" way: you have some sort of template engine that generates the whole HTML, a view method that makes the DB calls, etc., and only after all the work is done the HTTP headers are sent. Because this method allows the backend to add/change/remove headers at any point during the process, not just at the start.
Essentially the problem is that CF doesn't know what your server is running, and even an s-maxage=60 is going to look like a bug from the user's perspective if they go to /post?id=123, navigate to /edit-post?id=123, edit the post, go back to /post?id=123 and see the post unchanged.
What are you referring to with the origin needing to support HEAD requests? For HTTP conditional requests your origin just needs to support GET with if-none-match or if-modified-since. Then it responds with a 304 with no body if the cached version is still valid. The origin should, of course, be able to determine cache validity much more cheaply than rendering the whole page, which is usually as simple as checking a single timestamp in the database.
And, of course, you can still use cache-control to permit some duration of staleness, so that you don’t literally revalidate on every request.
1 reply →
> If you GET, the page is rendered. So in order for etag/last-modified to be effective, the CMS must implement HEAD.
No, you just implement GET properly so that nothing gets "rendered" for 304 Not Modified responses.
OTOH a CMS that doesn’t send correct cache headers is already broken