AEM AS Cloud | Images are showing 302 status in request log and access log in Author, publisher and dispatcher | Community
Skip to main content
Level 4
February 14, 2023
Solved

AEM AS Cloud | Images are showing 302 status in request log and access log in Author, publisher and dispatcher

  • February 14, 2023
  • 3 replies
  • 2308 views

We are using AEMaaCS and this issue is happening only in a cloud environment, not locally. In the page properties of a content page, we have authored "image" in the Thumbnail/preview tab. Now, this image gets rendered on the page. But the issue is, it's showing a 302 status code in the access/request logs. The interesting part is, it shows 200 status in the browser network tab. Due to this 302 status, images are not caching in the dispatcher. 

 

Here is the image path which shows in the logs

[cm-p46752-dsdsadsad-aem-publish-dewqeqq11-fj4zx] "GET/content/dam/xyz/test.png" 302 20ms

 

Note: This is not a core image component so the relative path (.../coreimg./...) is not relevant here. In my use case, I have authored the image in Thumbnail/preview tab and I would like to cache this image.

 

Note: The same image is caching fine in the local AEM SDK and not giving 302 status code. We are seeing 200 status.

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 joerghoh

This is normal and expected. Assume this flow:

 

  1. User requests /content/dam/asset.jpg in the browser
  2. Fastly receives this request, and this file is not in the CDN cache, so Fastly forwards this request to AEM publish
  3. AEM publish receives this request, and sends a redirect (statuscode 302) to the blobstore, where the binary can be served from.
  4. Fastly receives this 302, and follows the redirect to the blobstore.
  5. The blobstore returns the binary asset
  6. Fastly stores the binary in the CDN cache and also returns the binary to the requesting user.
  7. The user receives the binary with a statuscode of 200.

 

So this statuscode 302 is an implementation detail for assets, and it avoids that the binary is streamed from the blobstore via AEM to Fastly; instead Fastly retrieves it directly from the blobstore. That's a more efficient use of the AEM resources.

 

 

 

 

 

3 replies

Ritesh_Mittal
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
February 14, 2023

Hi @karanmahi ,

 

Please check if this existing thread helps, else let me know-

 

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/dam-asset-got-302-redirection-on-publisher/td-p/420929

 

Thanks,

Ritesh Mittal

karanmahiAuthor
Level 4
February 14, 2023

Hi Ritesh - I went through that link earlier, but that didn't help.

1. We don't have any custom rewriter

2. no etc mapping

3. no resource resolving mappings

4. and we are on cloud

5. Issue is happening in author logs also

Manu_Mathew_
Community Advisor
Community Advisor
February 14, 2023

@karanmahi This could be related to any HTTPs/SSL certificates that are installed/configured on the environments. 

karanmahiAuthor
Level 4
February 14, 2023

No. we didn't do any HTTPs/SSL certificates on cloud.

joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
February 18, 2023

This is normal and expected. Assume this flow:

 

  1. User requests /content/dam/asset.jpg in the browser
  2. Fastly receives this request, and this file is not in the CDN cache, so Fastly forwards this request to AEM publish
  3. AEM publish receives this request, and sends a redirect (statuscode 302) to the blobstore, where the binary can be served from.
  4. Fastly receives this 302, and follows the redirect to the blobstore.
  5. The blobstore returns the binary asset
  6. Fastly stores the binary in the CDN cache and also returns the binary to the requesting user.
  7. The user receives the binary with a statuscode of 200.

 

So this statuscode 302 is an implementation detail for assets, and it avoids that the binary is streamed from the blobstore via AEM to Fastly; instead Fastly retrieves it directly from the blobstore. That's a more efficient use of the AEM resources.