Stale Content Served via Firewall (Imperva) Layer Despite CDN and dispatcher Cache Purge | Community
Skip to main content
M
MohanJo1
Level 3
May 15, 2025
Solved

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

  • May 15, 2025
  • 1 reply
  • 669 views

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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by MohanJo1

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. 

1 reply

arunpatidar
Community Advisor
arunpatidarCommunity Advisor
Community Advisor
May 16, 2025

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.

Arun Patidar
    M
    MohanJo1AuthorAccepted solution
    Level 3
    May 16, 2025

    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. 

      joerghoh
      Adobe Employee
      joerghohAdobe Employee
      Adobe Employee
      May 18, 2025

      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.

        Terms & ConditionsAccessibility statement

        Loading footer...