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
Command icon 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

wouters_f created an issue. See original summary.

wouters_f’s picture

I think I created it.
Let me see if I can get this PR'ed.

fix i think
fix i think

wouters_f’s picture

Please review the placement of

addTargetedCacheHeaders

I am not sure if this is the right location.

wouters_f’s picture

Issue summary: View changes
wouters_f’s picture

Status: Active » Needs review
dieterholvoet’s picture

Status: Needs review » Needs work

I'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.

dieterholvoet’s picture

Title: Add support for the new cache headers (Targeted Cache-Control Cache-Status) » Add support for targeted cache-control headers
bkosborne’s picture

+1 to this!

bburg made their first commit to this issue’s fork.

bburg changed the visibility of the branch 3245475-add-support-for to hidden.

bburg’s picture

I 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:

  • "CDN-Cache-Control" - which can only be added once.
  • Service specific *-Cache-Control headers. "Akamai-" and "Cloudflare-CDN-" are available to select, but the user has an option to add a custom version where they provide the prefix screen.
  • You can also set all the directive settings for "visibility", "must-revalidate", "no-store", "no-transform", and "proxy-revalidate" as well as the max-age selection of time ranges (pulled from the existing implementation). You can add as many custom headers as you like, but only one "CDN-Cache-Control".

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)

Only local images are allowed.

dieterholvoet’s picture

Status: Needs work » Reviewed & tested by the community

I 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.

  • dieterholvoet committed 12237b10 on 8.x-2.x authored by bburg
    Issue #3245475 by wouters_f, dieterholvoet, bburg: Add support for...
dieterholvoet’s picture

Status: Reviewed & tested by the community » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

bburg’s picture

I 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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.