Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

URL management - AEM vs mod_rewrites


Level 5


For URL rewrites, vanity URLs, etc.. what would be pros and cons of doing it the 'AEM way' (etc/maps, resource resolver) vs doing it the traditional way of setting the rules in apache mod_rewrites?

Neither one seems author-friendly so what would underly choosing one over the other? In fact, in case of AEM, at least the first request for a page should go all the way to the instance for the URL conversion (subsequent requests will be fetched from the cache I'm guessing) whereas in case of apache it'll be returned from the server itself..

Just trying to understand ..


0 Replies


Level 2

Use mod_rewrites as much as possible. Main problem in this area is the connect between AEM & Dispatcher caching.

Cache flush on page activation is triggered only to the full AEM url & not to vanity or mapped path. Dispatcher caches content at the path it requested AEM with. If these 2 differ (and it would if you do url mapping of vanity url in AEM), cache flushing does not happen properly.


Level 5

Thanks Ashok.

Is there a case where AEM way of URL management is preferred over doing it in Apache. It looks like AEM converts all page URLs to its shortened form in the generated HTML. Would that be a valid advantage here over apache?


Level 2

AEM provides an easy way to map url's (setting vanity url's or page alias can be done by business authors themselves) and you don't need a server bounce to make this mapping effective.

This can be made use of when the page on which its applied does not get modified in the course of its lifetime. Say a campaign page. You design the final page, assign a short vanity path & publish it. It lives for sometime and is orphaned & deleted when a new campaign comes along for which a new page is designed and a new vanity path mapped

Another scenario when it can be leveraged is when your caching requirements are not stringent. If you have the dispatcher cache invalidation set at root level (which means any activation invalidates the whole dispatcher cache).