Stale Content Served via Firewall (Imperva) Layer Despite CDN and dispatcher Cache Purge

[MohanJo1]

Scenario: AEM Cloud

Our setup includes:

• AEM Publish endpoint behind Dispatcher and CDN (Fastly)

• A firewall layer (Imperva) in front of the CDN for public domain access (e.g., yourdomain.com)

Issue:

• When content updates are made and both the CDN and Dispatcher caches are purged, the changes reflect immediately when accessing the page through the publish endpoint (behind Fastly + Dispatcher).

• However, when accessing the same content via the public domain (yourdomain.com, routed through Imperva → CDN → Dispatcher → Publish), the old/stale content continues to appear until the TTL expires.

This suggests that stale content is being served on the request path that includes Imperva, despite cache purge operations.

Additional Context:

We have connected with the Imperva team regarding this behavior. They have confirmed that they are not caching any content on their end. According to them:

• They are only routing traffic from imperva to the Fastly CDN

• Imperva is being used solely for security and governance purposes, and not involved in any response-level caching.

Expected Behavior:

After purging cache, the content should reflect updated changes consistently across both:

• The direct publish endpoint

• The public domain (yourdomain.com)

Request:

We would appreciate guidance on:

• Whether any additional configuration or headers are needed to ensure consistent behavior when requests pass through the Imperva layer.

• If any known behavior exists in AEM/Dispatcher/Fastly setups that would cause this discrepancy when routing includes a third-party WAF.

Thank you for your support.

[arunpatidar]

Hi @MohanJo1 

Please check the cache-related headers in your content?

It's possible that caching is occurring at the browser level, especially if Cache-Control headers are used without proper directives for CDN caching.

To cache content only at the CDN level, consider using headers like s-maxage, which are specifically interpreted by shared caches (e.g., CDN) and not by browsers.

[MohanJo1 · Accepted solution]

Thanks @arunpatidar. I appreciate your input, but in this case, the issue wasn’t related to caching headers on the browser or CDN.

After extensive troubleshooting, we discovered that the root cause was tied to the host header. This is an important step when we have a custom CDN in front of Adobe's Fastly CDN. Here’s what we implemented to resolve it:

• The Imperva host redirect was updated to point to the publish endpoint, which sits behind the CDN and Dispatcher. 

[Jörg_Hoh]

There is no way to bypass the CDN and dispatcher layer, as the only publicly documented way to access AEM CS is via the hostname which is served via the CDN.