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

[karanmahi]

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.

[Ritesh_Mittal]

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-redirect...

Thanks,

Ritesh Mittal

[karanmahi]

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_]

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

[karanmahi]

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

[Jörg_Hoh · Accepted solution]

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.