Expand my Community achievements bar.

Why dont vanity urls work with cloud AEM?

Avatar

Level 9

We have been using AEM cloud for some years, but vanity urls have never worked.

 

E.g. this is our current page site format: oursite.com/uk/en/register.html.

 

if we want to have oursite.com/join or oursite.com/join.html, and add "join.html" as a vanity url for the register page, then try to hit oursite.com/join.html we get:

 

Resource at '/content/our-web/oursite_com/join.html' not found: No resource found

AEM requires quite a complex set of dispatcher rules to map the underlying page structures to site structure.  Development of these dispatcher rules takes a long time, as its not possible to run it locally (as the local dispatcher is http, not https, and aem has a lot of issues switching between the two when you use rewrite rules and redirects), so to test a one line dispatcher change, requires 2-3 hours to deploy it to an AEM cloud instance.

 

Any suggestions how to get vanity urls working?

 

Currently, when marketing want a new vanity url for a page, its 3-4 week lead time as we have to change the dispatcher, then do a complete release cycle along with other changes and all the testing.  This costs tens of thousands of pounds.

5 Replies

Avatar

Employee Advisor

First, the need to a full deployment to update dispatcher configuration will be removed soon. This will reduce the turn-around times dramatically.

 

Have you tried just "join" as vanity url? Of course there is no resource /content/oursite_com/join.html in the resource tree, but only /content/oursite_com/join.

 

Avatar

Level 9

yes, we have tried just join, same error unfortunately. The issue is that join does not exist, our page is called register.html.  There is no point in vanity url if it has to be identical to the url its being a vanity url for.  The url the browser uses for our site is oursite.com/uk/en/register.html.  We have dispatcher rules to rewrite this under the hood to /content/our-web/oursite_com/uk/en/register.html.  Vanity URLs dont work at all.  They not only dont rewrite to the actual page (register.html), but they get the path wrong also.  Presumably, to use vanity urls, requires some clever logic to be added to dispatcher, vanity urls will never work out of the box.  The question is, how do we setup AEM to work for vanity urls?  We cant find any guide or documentation on how to configure vanity urls.

Avatar

Level 9

Thats great news about being able to deploy dispatcher rules without a full deploy.  Any idea how this will work, as there is only one build option - you commit to a branch and AEM builds it.

Avatar

Employee Advisor

From what I understood it should be released (or rollout is already ongoing, not sure about the details), and then docs will be updated as well.

Avatar

Employee

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.1 - - [localhost/sid#55db2b3cbd10][rid#55db2b47d760/initial] init rewrite engine with requested uri /testing
[Thu Aug 19 17:23:59.345012 2021] [rewrite:trace1] [pid 52:tid 140570032655080] mod_rewrite.c(483): [client 172.17.0.1:56184] 172.17.0.1 - - [localhost/sid#55db2b3cbd10][rid#55db2b47d760/initial] pass through /testing
[Thu Aug 19 17:23:59.345376 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] Found farm publishfarm for localhost:8080
[Thu Aug 19 17:23:59.345514 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] checking [/testing]
[Thu Aug 19 17:23:59.345571 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] request URL has no extension: /testing
[Thu Aug 19 17:23:59.345588 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] cache-action for [/testing]: NONE
[Thu Aug 19 17:23:59.345635 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] Checking vanity URLs
[Thu Aug 19 17:23:59.345695 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] Vanity URL file (/tmp/vanity_urls) found, loading...
[Thu Aug 19 17:23:59.345780 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] Loaded 2 vanity URLs from file /tmp/vanity_urls
[Thu Aug 19 17:23:59.345841 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] Request URL is a vanity URL: /testing
[Thu Aug 19 17:23:59.345912 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] Creating new connection: host.docker.internal:4503
[Thu Aug 19 17:23:59.348924 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] Connected to backend 0 (host.docker.internal:4503)
[Thu Aug 19 17:23:59.531284 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] response.status = 200
[Thu Aug 19 17:23:59.531355 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] response.headers[Date] = "Thu, 19 Aug 2021 17:23:59 GMT"
[Thu Aug 19 17:23:59.531373 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] response.headers[X-Content-Type-Options] = "nosniff"
[Thu Aug 19 17:23:59.531389 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] response.headers[X-Frame-Options] = "SAMEORIGIN"
[Thu Aug 19 17:23:59.531406 2021] [dispatcher:debug] [pid 52:tid 140570032655080] [client 172.17.0.1:56184] response.headers[Content-Type] = "text/html;charset=utf-8"
[19/Aug/2021:17:23:59 +0000] "GET /testing HTTP/1.1" 200 none [publishfarm/0] 197ms "localhost:8080"