Understanding HTTP 302 responses for DAM assets in AEM as a Cloud Service
This article explains why HTTP 302 responses are seen for DAM assets in Adobe Experience Manager as a Cloud Service (AEMaaCS), clarifies when these redirects are expected, and provides guidance on distinguishing them from actual redirect issues in log monitoring.
Description description
In AEM as a Cloud Service, requests for large DAM assets result in HTTP 302 responses in Dispatcher logs. This behavior is part of the platform’s Direct Binary Access (DBA) design, where AEM Publish redirects asset requests to a cloud storage backend for efficient delivery. While end users and the CDN layer typically see a 200 OK response, intermediate 302 responses appear in internal logs, which causes confusion during monitoring or troubleshooting.
Environment
Adobe Experience Manager as a Cloud Service (AEMaaCS) (all versions)
Symptoms
- Intermittent HTTP 302 responses for DAM assets (For example:
/content/dam/<path>/asset.pdf) are seen in Dispatcher access logs. - These 302 responses aren’t reproducible from the client side; direct requests to the public URL return 200 OK.
- CDN logs show only 200/304 responses, not 302.
- Dispatcher logs show these requests as
[ action none]and don’t indicate the redirect destination. - Other DAM assets (such as images and PDFs) also show similar 302 responses.
- The 302 requests often lack User-Agent or Referrer information.
Cause
The 302 responses are generated by the AEM Publish DAM binary servlet as part of the Direct Binary Access (DBA) workflow. This servlet issues a HTTP 302 redirect with a Location header pointing to a cloud storage backend. The Dispatcher logs the 302 response, and the CDN layer follows the redirect, fetches the asset, and returns 200 OK to the client. This is expected and by design.
Resolution resolution
Follow the steps below to resolve the issue:
-
Understand that HTTP 302 responses for DAM assets in Dispatcher logs are expected when Direct Binary Access (DBA) is in use. These aren’t errors and don’t indicate a misconfiguration.
-
To distinguish expected DBA 302s from potential redirect issues in your monitoring:
-
Expected DBA 302s:
-
The request path starts with
/content/dam/.... -
Dispatcher logs show
[ action none]. -
The Location header in the 302 response matches a cloud storage URL pattern.
-
Potential redirect issues:
- 3xx responses for paths outside
/content/dam/... - Redirects driven by Apache RewriteRule or vanity URL configurations
- Location headers pointing to site roots, locale redirects, or login pages
- 3xx responses for paths outside
-
-
In your log monitoring tools, filter or annotate 302 responses that match the expected DBA pattern above to avoid false positives in redirect issue reporting. For example, you can filter for log entries where the path starts with
/content/dam/, and the response code is 302. -
Focus investigation on unexpected 3xx responses that don’t match the DBA criteria.
-
To verify, confirm that end users receive 200 OK for DAM asset requests via the public URL and that the CDN layer doesn’t report 302 responses.