Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

403 on images from Dispatcher

Avatar

Former Community Member

We're experiencing an odd issue with our Dispatchers and some of the images in our content tree. In some cases, requests for images are returning a 403 status. The really odd thing is that this only seems to happen after the Dispatcher has actually cached the image. If the Dispatcher cache is empty and an image is requested it will be requested from the pub, delivered to the requester, and cached. All subsequent requests result in a 403 response. 

I saw this post that mentions the (https://dev.day.com/docs/en/cq/5-4/deploying/dispatcher.html) Dispatcher returning 403's, but the article says that issue is only on Apache 1.3 and we're running Apache 2.2

1 Accepted Solution

Avatar

Correct answer by
Former Community Member

We found out what the issue was. The image URLs contained "jcr:content". The CQ link checker rewrites / mangles this to "_jcr_content". That wasn't happening in our case because the URL was being stuck in a data attribute and pulled in via AJAX. On a Linux server this wouldn't matter. However, ':' is an invalid filename character in Windows, so the cached image was never being created. The request worked if the cache was empty because the request simply got forwarded to CQ which has no problem with ':'s. On subsequent requests, though, the Dispatcher would note the URL should be cached and attempt to retrieve it. The retrieval then failed and a 403 response was sent. 

So the solution is to avoid ':'s in URLs. Or, even better, avoid Windows servers. 

View solution in original post

4 Replies

Avatar

Correct answer by
Former Community Member

We found out what the issue was. The image URLs contained "jcr:content". The CQ link checker rewrites / mangles this to "_jcr_content". That wasn't happening in our case because the URL was being stuck in a data attribute and pulled in via AJAX. On a Linux server this wouldn't matter. However, ':' is an invalid filename character in Windows, so the cached image was never being created. The request worked if the cache was empty because the request simply got forwarded to CQ which has no problem with ':'s. On subsequent requests, though, the Dispatcher would note the URL should be cached and attempt to retrieve it. The retrieval then failed and a 403 response was sent. 

So the solution is to avoid ':'s in URLs. Or, even better, avoid Windows servers. 

Avatar

Level 6

Hi ,

Can you paste here your dispatcher error log for furthur drill down?

Avatar

Level 8

Thanks for following up with the solution

Avatar

Level 8

Can you post your dispatcher.any file?

scott

The following has evaluated to null or missing: ==> liqladmin("SELECT id, value FROM metrics WHERE id = 'net_accepted_solutions' and user.id = '${acceptedAnswer.author.id}'").data.items [in template "analytics-container" at line 83, column 41] ---- Tip: It's the step after the last dot that caused this error, not those before it. ---- Tip: If the failing expression is known to be legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: #assign answerAuthorNetSolutions = li... [in template "analytics-container" at line 83, column 5] ----