AEM Dispatcher - Troubleshooting Filters

If you have worked with Adobe Experience Manager long enough, eventually you will find yourself trying to figure out why a page, asset, or other call is returning a 404 at the dispatcher but working fine on Author and Publish instances.

The most common problem is a dispatcher filter blocking the call at the webserver and not allowing the traffic to make it to the Publish instance(s).  

What is a Dispatcher Filter?

Without getting too technical, dispatcher filters can be thought of as ACLs applied at the webserver. 

The main purpose is to provide an extra layer of security by preventing public access to the protected areas of the Author and Publish instances.  But don't these areas require credentials with proper permissions in AEM? Yes, but with properly written dispatcher filters, you don't even allow users to get prompted for a password, thus adding an extra layer between the public and your AEM instance(s).

Dispatcher Log

By default, the dispatcher is set to 'info' and logs all output to the dispatcher.log file located typically with your web server log files.

When the dispatcher log level is set to 'debug', it will print to the log file that the request was rejected due to a filter rule.

[Thu Jun 11 21:35:55 2020] [D] [pid 66692] Filter rejects: 
GET /content/dam/<project_folder>/AdobeStock_edited.jpg.transform/2x1x/image.jpg HTTP/1.1

But which one?

If we change the dispatcher log level to 'trace' or loglevel '4' and restart the dispatcher, the logs will now tell us more about the request and the specific filter that denied that request. 

[Thu Jun 11 21:35:55 2020] [T] [pid 66692] 
Filter rule entry /0001 blocked 'GET /content/dam/<project_folder>/AdobeStock_edited.jpg.transform/2x1x/image.jpg HTTP/1.1'

Looking at the actual request and the filter that rejected that request, you should now be able to update or create a new rule to allow that call and other calls matching it.