CDN-Cache-Control header necessary for SlickStack or not?

[jessuppi]

Last year, Cloudflare promoted a new HTTP header called CDN-Cache-Control which we should research in more depth and determine if it's relevant and useful to SlickStack: https://blog.cloudflare.com/cdn-cache-control/

[jessuppi]

This example is shared on the Cloudflare blog post above...

Before

Headers:

Cache-Control: stale-if-error=400

Behavior in response to 5XX Error:

Caches	Stale served (seconds) in response to error
Origin Cache Layer	400 (if it assumes the directive applies)
Cloudflare Edge	400 (we assume the directive applies if we get it from upstream)
Unknown CDN/Network caches/Browser Cache	0 (if they assume the directives doesn’t apply or they don’t get them from upstream); or 400 (if they do assume it applies)

Now (explicit indication of when directives apply to CDNs)

Headers:

Cache-Control: stale-if-error=400 Cloudflare-CDN-Cache-Control: stale-if-error=60 CDN-Cache-Control: stale-if-error=200

Behavior in response to 5XX Error:

Caches	Stale served (seconds) in response to error
Origin Cache Layer/Network Cache/Browser Cache	400 (if it assumes the directive applies)
Cloudflare Edge	60
Other CDN	200

[jessuppi]

Since we don't envision SlickStack being used alongside complex load balancing or multi-layer stacks per se, I don't think some of the examples Cloudflare offers would be relevant...

However, the "serve CDN stale in case of origin error" could be rather useful for a simple stack like ours. It's sounds sort of like Cloudflare's "Always On" feature, however, it could be more powerful in that we have more control over how long the assets are cached for, and I also assume potentially MORE assets would be cached if this header exists? Then again, what good is it to have CDN assets cached if the HTML from the origin is not loading?

For the past few years we've also used more_clear_headers "Pragma Expires Cache-Control"; in our Nginx configuration to avoid browsers caching HTML, which has worked very well for our users... the issue being that modern browsers will cache assets anyways (even if you tell them not to), not to mention that static assets are set to expires max in SlickStack already which is mirrored/overwritten by Cloudflare headers... so this helps to ensure dynamic content is readily viewed by end users, esp. since the bulk of asset caching should be done via your CDN such as Cloudflare these days.

For now, since we don't use Cache-Control I think we can safely ignore CDN-Cache-Control for now, and try to educate SlickStack users on Cloudflare's default asset cache settings.

Some useful reading: https://www.peakhour.io/blog/cdn-cache-control-header/