Last I checked months back, Vanity urls used to work well in AEM CS environments. Have you replicated the behavior on your dispatcher SDK running locally? I would suggest to enable debug logging for dispatcher module and the rewrite engine to surface the real problem. Below are the logs captured for a test and you can match if you can see the flow of vanity urls [Thu Aug 19 17:23:59.344882 2021] [rewrite:trace2] [pid 52:tid 140570032655080] mod_rewrite.c(483): [client 172.17.0.1:56184] 172.17.0....

The geolocation headers are coming from CDN to the origin. The flow should be something like request -> cdn -> (cdn appends headers) -> dispatcher -> aem so one needs to fetch it on apache and redirect or do things. If the headers are not visible in the flow(you need to explicitly log it to see them), you should reach out to AEM Support or your CSME along with your dispatcher configs to review.

For customer environments, Stage+Production environment are auto-updated with latest releases. For every release that Adobe pushes, There is a strict testing regime where the release is tested on many customer environments to avoid any regressions. These tests include functional, UI variance and other forms of testing to have a confidence score which help decide if the release is ready for customer consumption. On the top of it, Customers can add Functional tests for their application and once A...

There is no specific setting needed on Cloud Manager front. Can you replicate this issue on your local dispatcher sdk setup ? Also, Switch on the debug logs for dispatcher + trace level logging for the rewrite engine so it surfaces whats actually happening on your dispatcher module and creating this problem Share the debug logs if you can here

Can you replicate this issue on your local dispatcher sdk setup ? Also, Switch on the debug logs for dispatcher + trace level logging for the rewrite engine so it surfaces whats actually happening on your dispatcher module and creating this problem Share the debug logs if you can here

Hi, What's the AEM SDK version you are using? Also, Java version plays a big role here. Download the latest AEM sdk along with Java 11 to start the AEM local runtime. For all the setup requirements, Review [1] [1] : https://experienceleague.adobe.com/docs/experience-manager-learn/cloud-service/local-development-environment-set-up/aem-runtime.html?lang=en

which index files do you delete? under /crx-quickstart/repository? This shouldn't be the case unless there is some corruption in the repository or aem is not started with the correct permissions. I would suggest to review the error logs at the time of startup to understand if you see any repository specific exceptions which can be linked back to a problem with the repo or the file permissions.