Why Your Sling Filters Don’t Affect Asset Headers in AEMaaCS?

[#1]

Why Your Sling Filters Don’t Affect Asset Headers in AEMaaCS?

by @daniel-strmecki

Introduction

When we make a request to fetch an asset from AEM as a Cloud Service (AEMaaCS), our request doesn’t go straight to the AEM Publish instance. Instead, it’s handled by Adobe’s OOTB CDN, which sits in front of AEM Publisher and serves cacheable content directly from the edge.

If the asset isn’t already cached, the CDN may fetch it from the cloud storage backend where AEM Assets binaries are stored. This storage layer behaves like a blob store and is fully managed by Adobe. Once retrieved, the response is cached at the CDN and served directly from there. Therefore, AEM Publisher is no longer involved in most asset delivery requests.

Because of this new cloud architecture, Sling Filters or Servlets that modify response headers don’t affect CDN-served assets. We can still implement response.setHeader() inside AEM, but unless the CDN explicitly allows that header to be forwarded, it won’t appear in the response sent to the end users.

To handle this properly, Adobe recently added a new CDN configuration property that allows us to override headers for assets.

Key points

Override Headers with CDN Config

Adobe provides a YAML-based CDN configuration, which is defined in a file named cdn.yaml, located in a specific project root folder, usually /config. It lets us configure caching rules, request/response manipulations, and other CDN behaviors that control how the OOTB CDN behaves. One of the response transformation properties recently made available by Adobe is overrideBlobHeaders, which allows us to define headers to preserve or override from AEM’s response before serving assets. To deploy a CDN configuration, we need to configure and run a dedicated Config Pipeline in Cloud Manager. Config Pipeline will validate and deploy these settings to the OOTB CDN. The config update is applied almost instantly to the target environment without affecting AEM or Dispatcher.

Add Headers with Sling Filters
Once the OOTB CDN is set up to preserve our custom header, we can use a simple Sling Filter to dynamically set the header value for any requested asset. To target specific asset types, the filter can be updated to use the resource_pattern attribute in the @SlingServletFilter annotation to match only certain file extensions. For example, using a regex such as /content/dam/.+\.(pdf|docx|pptx)$ ensures the filter only runs for those asset types, keeping it efficient and precise.

Test with AEM Mocks
We can verify our filter behavior using AEM Mocks, ensuring the header logic runs correctly. Our example test calls the doFilter method directly to test only our filter’s logic without depending on Sling’s full request pipeline. This makes unit tests faster, reliable, and focused, avoiding issues with servlet resolution and slow Oak setup. End-to-end behavior, including CDN, still needs to be verified manually on an AEMaaCS environment.

Full Article

Read the full article on https://meticulous.digital/blog/f/why-your-sling-filters-don%E2%80%99t-affect-asset-headers-in-aemaa... to find out more.

Q&A

Please use this thread to ask questions relating to this article.

[#2]

@daniel-strmecki Fantastic deep dive. Thanks for breaking down the role of Adobe’s OOTB CDN layer so clearly! 

Quick question for you: when working with cdn.yaml and overrideBlobHeaders, how do you usually balance between setting headers via CDN config vs dynamically through Sling Filters? In your experience, when is it better to let the CDN handle all header overrides versus pushing some logic into AEM for flexibility or environment-specific behavior? Would love to hear how you decide that trade-off in real-world projects.

[#3]

Hi @kautuk_sahni,

thanks. CDN config response transformations are designed for lightweight header adjustments, such as removing sensitive headers or adding simple security headers. When we need dynamic header behavior, we need to set those headers in AEM or Dispatcher. Then we can whitelist them in the CDN config, if they are not whitelisted already OOTB.

[#4]

Hi @daniel-strmecki ,

Appreciate you for sharing this.