While working on client sites and delivering AEM training, occasionally the dispatcher would not be caching content as expected.  For example, when setting up a default dispatcher and trying to cache Geometrixx Outdoors pages, I would get the following output in the log:

request contains authorization
cache-action for [/content/geometrixx-outdoors/en.html]: NONE

The simple and quick solution for this is to allow caching of authorised content with the dispatcher setting:

/allowAuthorized "1"

However this setting now allows caching of secure content, which may be a security concern.  My thoughts were along the lines that Geometrixx Outdoors allows logins, so for some reason all requests are returning the authorised header, and therefore telling the dispatcher not to cache the request without this setting.

But on a current implementation I’m working on, there is no login or secured content and the dispatcher is still telling me that the request contains authorization and is not caching.

It turns out that the culprit was my browser. I had the Author interface open in one tab, and the published content in another tab. The browser was sending the authorisation tokens from the Author instance to the Dispatcher, as it’s all the same machine (my local development server) in the same browser session. After opening the dispatcher request in an incognito tab, the authorisation header was not being sent, and the dispatcher was caching as expected.

So remember, don’t simply set /allowAuthorized to “1” in order to solve an authorisation problem unless you actually have secured content that you want to cache – there may be other reasons your dispatcher is thinking your request contains authorisation headers.