Proper ETag Support Finally Arrives in the AEMaaCS Dispatcher
Proper ETag Support Finally Arrives in the AEMaaCS Dispatcher
Introduction
Reducing unnecessary network traffic is a core goal of HTTP caching, and one of the most effective mechanisms for achieving this has been part of the protocol for decades. ETags allow different layers of the web stack to determine whether a resource has actually changed before transferring it again, making them a powerful tool for improving performance and cache efficiency.
In modern architectures where browsers, CDNs, reverse proxies, and origin applications all participate in content delivery, ETags play an important role in enabling efficient validation of cached content. Instead of repeatedly sending the same payload across the network, each layer can simply verify whether the cached representation is still valid.
Despite this being a fundamental HTTP capability, many AEM implementations have historically not been able to fully benefit from ETag validation across the entire delivery stack. While the mechanism worked correctly in some parts of the architecture, there was a particular AEM cache layer where the expected behavior did not occur. To understand why, it is useful to first revisit how ETags work and how they are intended to operate across multiple caching layers.
Key points
Why ETags Matter for Web Performance
By enabling proper ETag validation between the CDN and Dispatcher layers, conditional requests can now function across the entire AEM delivery pipeline. This reduces unnecessary content transfers and allows existing HTTP caching mechanisms to operate as originally intended.
Conditional Requests Reduce Unnecessary Data Transfer
When a client includes the If-None-Match header with a previously received ETag value, the server can determine whether the resource has changed. If the content is identical, the server responds with a 304 Not Modified status and no response body, allowing the client to reuse its cached version and avoid downloading the resource again.
ETag Validation Works Across Multiple Cache Layers
Although ETags are often described as a browser optimization, they are designed to function across the entire delivery chain. Browsers, CDNs, reverse proxies, and origin applications can all participate in conditional request validation, allowing each layer to confirm that cached content is still valid before requesting or transferring the full response.
The Historical Limitation in AEM Architectures
In AEM environments, ETag validation historically worked between the browser and CDN, but the mechanism broke down at the Dispatcher layer. When a CDN revalidated expired content using the If-None-Match header, Dispatcher did not properly evaluate the request against its cached response and returned the full response body instead of confirming that the content had not changed.
The Impact on CDN Revalidation
Because Dispatcher did not respond with 304 Not Modified, unchanged content was repeatedly transferred from Dispatcher to the CDN whenever the CDN cache expired. In high-traffic environments where CDNs frequently revalidate cached resources, this behavior resulted in unnecessary bandwidth usage between infrastructure layers.
Generating ETags in the Application Layer
For conditional request validation to work, the origin application must generate ETag values for its responses. In AEM implementations this is typically done using a servlet filter that calculates a digest of the response content and attaches it as the ETag header, allowing downstream caching layers to validate cached resources correctly.
Improved ETag Handling in Dispatcher
With AEMaaCS SDK version 2026.2.24464, Adobe introduced improved handling of conditional requests involving ETags. Once the feature flag is enabled, Dispatcher can properly evaluate If-None-Match headers against its cached responses and return 304 Not Modified when the resource has not changed.
Completing the Conditional Request Chain
By enabling proper ETag validation between the CDN and Dispatcher layers, conditional requests can now function across the entire AEM delivery pipeline. This reduces unnecessary content transfers and allows existing HTTP caching mechanisms to operate as originally intended.
Full Article
Read the full article on https://meticulous.digital/blog/f/proper-etag-support-finally-arrives-in-aemaacs-dispatcher to find out more.
Q&A
Please use this thread to ask questions relating to this article