Issues with vanity_url rule on dispatcher

check if your dispatcher blocking your request.. check in the filter section or enable the debug logs in the dispatcher and see what is the exact error.

Hi,

I tried localhost:4503/libs/granite/dispatcher/content/vanityUrls.html and it lists all the vanity urls and also I can access the vanity url though localhost:4503/testVanityUrl.html but still not able to access via dispatcher and got 404 error - "Unable to fetch vanity URLs from localhost:4503/libs/granite/dispatcher/content/vanityUrls.html: remote server returned: HTTP/1.1 404 Not Found".

I have already given the READ permission to "everyone" group as well as to "anonymous" user but no luck. I have allowed the path in /filter section but not sure if anything needs to be done in /cache section.

Please suggest.

Thanks,

Jitendra

Hi,

I am not able to access vanity url s starts with home ex:/homecare, /homehealth any string starts with home.

I commented the entry

RewriteCond %{REQUEST_URI} !^/home

in dispatcher  stilL it is not resolved.please help on this

Hi Anand,

Have you found the solution . Any luck?

Thanks & Regards,

Vijay

Hi Kristian,

I have followed your blog and set up everything as given. But I am also getting same problem. First time the temp file gets created properly. But It is not getting updated when we introduced new vanity url.

Could you please suggest here.

Thanks & Regards,

Vijay

Hi Anand,

Try setting the read property for the group 'everyone' on the /libs/granite/dispatcher/content/vanityUrls node, and update your dispatcher /url setting to /libs/granite/dispatcher/content/vanityUrls.html

This is how Daycare suggested to solve it and it's working for me.  Also don't forget to allow that path in the dispatcher filter and also prevent it from being cached.

Cheers
K

Hi Kristian,

I have set the delay to 60 and restarted my apache. I have updated a vanity URL in one of the page and published. After waiting for 30 min and when I tried to access vanity url , it’s going to 404.

Following is the dispatcher log.

[Fri Feb 12 23:09:12 2016] [D] [7672(2900)] Found farm website for www.localhost [Fri Feb 12 23:09:12 2016] [D] [7672(2900)] checking [/my-smart-url] [Fri Feb 12 23:09:12 2016] [D] [7672(2900)] request URL has no extension: /my-smart-url [Fri Feb 12 23:09:12 2016] [D] [7672(2900)] cache-action for [/my-smart-url]: NONE [Fri Feb 12 23:09:12 2016] [D] [7672(2900)] refresh_vanity_urls: up-to-date (next check: 18443758385699362565, current: 0) [Fri Feb 12 23:09:12 2016] [D] [7672(2900)] Filter rejects: GET /my-smart-url HTTP/1.1 [Fri Feb 12 23:09:12 2016] [I] [7672(2900)] "GET /my-smart-url" - - 1ms

Regards,

Anand

Hi Anand,

For debugging, set delay to 60, and your dispatcher log to debug.  If you can post the dispatcher log when you try and access the vanity URL that might give a clue as to why it's not updating...

Overall you should not need to restart the server, only restart apache after changing configurations.

Cheers,
K

Hi Kristian,

For the first time after my server restart, the vanity_url file is created when i tried accessing vanity URL from my browser. but later the file is not being refreshed even after i waited for an hour and hit new vanity URL that i configured. below is my setting in dispatcher.any

/vanity_urls {
     /url "/content/vanityUrls.html"
     /file "/tmp/vanity_urls"
     /delay 200
    }

Regards,

Anand

Hi Anand,

Thanks for the update.  I created a Daycare ticket about this, and they suggested adding a read permission to the 'everyone' group for the node '/libs/granite/dispatcher/content/vanityUrls'.  This works, as does your solution.

I also needed to make some other changes that were not documented, such as allowing /libs/granite/dispatcher/content/vanityUrls in the dispatcher filter rules, and also ensuring it was not being cached.

As to your initial question above regarding the file defined in /file not being created, it turns out that it's not automatically happening every /delay seconds, but rather only when a page that fails the filter is being requested.  So this explains why it's sometimes being written and updated - the /delay is not how often the dispatcher checks, but rather how old the file can be to be considered out of date before fetching an updated version.

I've blogged about this complete solution here:  https://blog.kristianwright.com/2016/02/11/aem-dispatcher-and-vanity-urls/

Thanks,
Kristian