Problem/Motivation
Read more details here: https://httptoolkit.tech/blog/status-targeted-caching-headers/
The spec itself is written by authors representing Fastly, Akamai and Cloudflare, so it's got good industry support already, and it's far enough through the process that it's unlikely to change drastically.
Today, both Cloudflare and Akamai already support this, so if you're using those caches you can start precisely configuring both with CDN-Cache-Control, Akamai-Cache-Control and Cloudflare-CDN-Cache-Control right now. It's pretty likely that there'll be similar support in the pipeline for many other tools and services, so watch this space.
Proposed resolution
Add support for the Targeted Cache-Control so that Drupal can maniupulate/control edge side caches.
eg.
<Target>-Cache-Control: param, param=value, param...
User interface changes
Maybe initially a textfield that alllows the user to enter manually one per line,
Ideally a way to enter lines with keys (cache name) and values (could be ttl or even advanced params).
API changes
Headers outputted:
Client-Cache-Control: must-revalidate
CDN-Cache-Control: max-age=600, stale-after-revalidate=300
Squid-Cache-Control: max-age=60
Cache-Control: no-store| Comment | File | Size | Author |
|---|
Issue fork http_cache_control-3245475
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
wouters_f commentedI think I created it.
Let me see if I can get this PR'ed.
Comment #4
wouters_f commentedPlease review the placement of
I am not sure if this is the right location.
Comment #5
wouters_f commentedComment #6
wouters_f commentedComment #7
dieterholvoet commentedI'm not a big fan of having users enter complete headers manually in a text area. It feels like a step backward with the user friendly UI we have now. Even if we would go down that route, we would need validation to make sure only targeted cache-control headers are entered. Now, any header can be injected into responses by adding it to that text area.
I guess the most user friendly way to go about this would be to allow people to add new targets, reorder them and for each target allow to change the different settings we already have now. That sounds like a lot of work though, for such a niche feature and also one that is still a proposed standard.
If someone wants to create this I'll be happy to review and merge it, but this is not something I'm going to spend much time on.
Comment #8
dieterholvoet commentedComment #9
bkosborne+1 to this!
Comment #12
bburgI don't think this is a niche issue at all, it seems that the Surrogate-Control header is not supported by all CDN services (Fastly and Cloudflare I believe are the big ones that do support it). Akamai seems to not support it, and it seems the site I'm working on in particular had this module installed under the impression that it did. I'm not sure if there is a difference in opinion on this, but it seems that the original spec proposal for targeted cache headers included representatives from all three. I'm uncertain if Fastly actually supports it yet, but it seems to be the standard these services are moving toward collectively.
Since this we are going in a different direction than the original pull request for this issue, I created a new branch, this creates a new set of form elements that can be added for multiple target cache control headers. Including a:
Full disclosure, a lot of this code was written by AI. Specifically the ChatGPT 5.2 "Thinking" model. I have reviewed it myself, and the changes work as advertised.
I did spot one bug in this initial branch where it seems that there are duplicate "No Caching" options for the max-age select. One being pulled from the existing options, and we are adding our own redundant version. It would also be nice to restrict the vendor specific options you can add based what is already in use.(fixed)Comment #14
dieterholvoet commentedI reviewed the code, tested it on an existing website and validated the new config using Configuration Inspector. Looks great! I'm going to leave this a couple weeks for other people to test and unless anyone objects I'll merge and release it after.
Comment #16
dieterholvoet commentedComment #18
bburgI just wanted to provide an important note here. While this blog post may make one think that Akamai currently supports the Targeted Cache Control header, I think that it hasn't been adopted yet. I confess I was confused, and under the impression that they did myself, but I just tested this on Akamai, and I don't see caching behave as I would expect. I'm going to submit a support ticket to Akamai, to have them confirm this. I also sent an email to the author of the post to confirm their knowledge as well, although it seems that they may no longer work at Akamai.