AEM 6.5 withsamplecontent. A simple configuration of my /etc/map configuration to remove /content/we-retail & .html is causing one major issue The resolved page keeps on 301 redirecting the request from http://localhost:4503/us/en to http://localhost:4503/us/en/... When I try to forcefully remove the slash from the dispatcher web server, I am getting an infinite loop because of the AEM publisher keeps on 301 redirecting the request to http://localhost:4503/us/en/ (with the extra slash...).
✓Remove "/content/we-retail" prefix on URL. (is working)
✓Remove ".html" from Extension(is working)
✓Magic of the Sling Resolver should rewrite all urls to non .html and non /content/we-retail (is working)
❌No trailing slashes should exist (301 redirect is always happening) -- The problem really comes when I have the dispatcher connected to my publisher.
Can someone please take a look at my configuration below, and let me know what is wrong with it? (very basic config)
Also can someone please explain what on earth is happening behind the scenes with all the AEM server-side redirects when sling mappings are configured. There's no documentation anywhere that talks about this.
I had a similar issue like this in the past with my personal project. The problem here is that you have multiple cached directories for http://localhost:4503/us/en. When you check your cached directories, you may the long path, /content/we-retail/us/ca/* AND (possibly) /us/ca/*.
Your configuration below looks fine. You should make sure one cached directory is in use. Use Apache mod_rewrite, rewrite rules, to internally redirect all /us/ca to the long path, /content/we-retail/us/ca/*, and the trailing slash should be magically removed. Since there are possibly two cached directories, even when you have a rewrite rule to redirects all requests of trailing slash to non-trailing slash, you will get infinite redirects happening.... because of the multiple cache directories for the given page.
The dispatcher does actually log a request, however, the request logged something like: fetching or http://localhost:4503/us/en/; yes straight to the slash, while the client sees a 301 redirect. This Is very weird. The dispatcher does not log anything else to determine how the redirecting of the trailing slash is done. Making sure there is only one root caching directory for the requested page should solve the issue.