Image Replacement in DAM Not Reflecting on Author Instance Due to Caching

[RahulSi13]

We are seeing an issue in AEM Author when replacing existing DAM assets with a new file that has the same name.
Below are the steps followed that lead to the issue:

1. Navigate to /content/dam/

2. Click Create → upload an image file that has the same name as an existing file

3. When prompted that a file already exists → select Replace

4. The file gets replaced successfully in DAM

However, on pages where the image is used via DAM reference (for example as /content/dam/...image.png), the updated image does not reflect in the component rendering. The page still displays the old image even though the DAM asset has been replaced.

Upon inspecting the network request of the image in the page, we see the following cache headers applied:

cache-control: private, max-age=43200, immutable

This behavior is observed in Author instance and seems to happen specifically for asset URLs referenced directly from /content/dam/....

It appears that the browser is serving the cached version due to the immutable directive, so the updated file is not fetched unless the URL changes or cache is manually cleared.

Could someone help with guidance on how to reduce the cache timing or clear the cache?

@arunpatidar 

[manikandan90]

@RahulSi13 ,

You can try reactivate and/or page/asset. For the permanent fix, set the dispatcher rule shown below.

<Location ~ ".+.{1}(?i:adsklib|asc|avi|csv|dfx|doc|docx|dot|dwg|dfx|dxf|edrw|enc|eps|flv|gif|gsm|ico|ifc|igs|jfif|jpe?g|lcf|mov|mp3|mp4|mp?g|pdf|pln|png|ppt|pptx|psd|rar|raw|rfa|rvt|svg|webm|webp|wma|xls|xlsm|xlsx|xltm|zip)$">
        # Important - Cache control is set to immutable by AEM
        Header unset Cache-Control
        Header always set Cache-Control: max-age=43200
    </Location>

[DPrakashRaj]

May be it’s happening because of browser local cache as it’s happening on author instance.

try checking this in private/incognito to see if this resolves. You can also select the disable cache from browser settings 

[MukeshYadav_]

Hi @RahulSi13 ,

You may use below rules if want to store (cache) in browser (not at cdn) but revalidates with a light request each time before serving from cache.

<LocationMatch "^/content/dam/.*\.(?i)(jpg|jpeg|png|gif|pdf)$">
    Header unset Cache-Control
    Header set Cache-Control "private, no-cache, must-revalidate"
</LocationMatch>

1. The Container: <LocationMatch ...>

This tells Apache: "Only apply these rules if the URL matches the specific pattern inside quotes."

• ^ (Caret):

  • Meaning: "Starts with."

• /content/dam/:

  • Meaning: The literal path where AEM stores assets.

• .* (Dot Star):

  • Meaning: "Any character, any number of times."

  • Why: This accounts for any folder structure (e.g., /content/dam/projects/2025/marketing/).

• \. (Escaped Dot):

  • Meaning: A literal dot (.).

  • Why: In Regex, a plain . means "any character." By putting a backslash \ in front, we say "I specifically mean the dot that separates the filename from the extension."

• (?i) (Case Insensitive Flag):

  • Meaning: "Ignore upper/lowercase differences."

  • Why: This ensures the rule works for image.png, IMAGE.PNG, and Image.Png. Without this, your rule would fail on uppercase uploads.

• (jpg|png|...):

  • Meaning: "One of these options."

  • Why: You only want to target binaries (images/documents). You usually do not want to target .html or .json with this specific rule.

• $ (Dollar Sign):

  • Meaning: "Ends here."

  • Why: This is crucial. It ensures the URL ends exactly with .png. It prevents the rule from matching something like image.png.bak or image.png/jcr:content.

2. The Cleanup: Header unset Cache-Control

• Header: The Apache command to modify HTTP headers.

• unset: "Delete this header if it exists."

• Cache-Control: The specific header that controls browser caching.

• Why do this? AEM or the Dispatcher might have already added Cache-Control: max-age=43200, immutable. If you simply add a new header without unsetting the old one, you might end up with two headers, or a merged mess like max-age=43200, no-cache, which confuses the browser.

3. The New Rule: Header set Cache-Control ...

• set: "Create this header. If one already exists, overwrite it."

• "...": The value string containing the three directives below.

A. private

• Meaning: "This file is for the end-user's eyes only."

• Technical: Do not store this file on shared public proxies (like CDNs, ISPs, or corporate office caches).

• Why for Author: In an Author environment, you might have sensitive, unreleased assets. You don't want a generic network cache storing them.

B. no-cache

• Meaning: "Store it, but check it." (The 'Doorman' Rule).

• Technical: The browser IS allowed to save the image to the hard drive (Disk Cache). However, before showing it to the user, the browser MUST send a request to the server (AEM/Dispatcher) to ask: "I have ETag 123. Is this still the current version?"

  • If AEM says "Yes" (HTTP 304), the browser shows the saved file.

  • If AEM says "No" (HTTP 200), the browser downloads the new file.

• Why for Author: This solves your problem. It eliminates the delay when replacing an image.

C. must-revalidate

• Meaning: "Strict enforcement."

• Technical: "If you cannot reach the server (network error, server down) to check the validity of the file, DO NOT show the old file. Show an error instead."

• Why for Author: It prevents "Stale-on-error." It ensures that what the Author sees is always the truth, even if the internet connection is flaky.

 
If you don't have dispatcher for author - Use ACS commons to put cache-control headers on requests by creating a OSGi config file for  com.adobe.acs.commons.http.headers.impl.DispatcherMaxAgeHeaderFilter for a given pattern.

Thanks,
Mukesh

[RahulSi13]

Hi @MukeshYadav_ ,

I tried configuring the OSGi file for com.adobe.acs.commons.http.headers.impl.DispatcherMaxAgeHeaderFilter using the following pattern:
{
"filter.pattern": ["/content/dam/.*\\.(jpg|jpeg|png|gif|pdf|svg|webp|ico)$"],
"max.age": 0
}

However, on the Author instance, the Cache-Control: private, max-age=43200, immutable header is still being applied. Could you please suggest if any additional configuration is required to override this on Author?

[arunpatidar]

Hi @RahulSi13 

You may need to rethink caching strategy, you have no control to invalidate the user's browser cache.
You can disable browser cache for those images in Author instances or serve image differently like Core Component's Adaptive Image Servlet

https://experienceleague.adobe.com/en/docs/experience-manager-core-components/using/developing/adapt... 

[RahulSi13]

Hi @arunpatidar ,

Thank you for your response.

If we continue using the image reference directly from /content/dam/..., is there any way to override or change the cache-control rule that is currently being applied in the author instance? We are specifically looking for an option to bypass or adjust this default caching behavior when serving DAM assets.

[arunpatidar]

Hi @RahulSi13 

Yes, you set different cache control header in Author, you need to adjust this on dispatcher but if you are on AEMaaCS then you need to do it at CDN level. 

[RahulSi13]

@arunpatidar ,

Thanks again for your reponse.

Could you please mention what would be changes that would be required at CDN level to control the cache-control header in the Author Instance.

[arunpatidar]

Hi @RahulSi13 

You can add a rule for author CDN domain to override cache-control header for DAM asset

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/con...