Hello -
We have lots of pages in our AEM Publisher that end up returning a 302 or 301 redirect response.
Is there any way to configure Dispatcher to cache those, so they don't make their way to the publisher each time?
I tried turning on the "header caching" for the "Location" header, but that didn't seem to help.
I see articles on the Internet about setting up a Varnish cache to do this, but that's not feasible in our environment, hence why I am hoping there is a way to do it with Dispatcher.
Thanks!
Tim
Solved! Go to Solution.
Views
Replies
Total Likes
Before the dispatcher supported vanity urls, it was a common approach to generate a parts of the apache config dynamically on the publisher.
Therefore on the Apache each virtual-host defintion contained an optional include for a dynamically generated config-snippet. On the publisher was a servlet - which generated these config snippets (typically a lot of mod_rewrite rules for vanity-urls and redirects). A cron-job on Apache (= dispatcher) server called the servlet every 10 minutes, placed the generated configuration into the right place and made the Apache to reload the configuration (soft restart = no downtime). Nicer solutions generated a zip-file cointaining all configuration-snippets in a single archive. Also the cron job should let the Apache check the syntax of the configuration first. Otherwise there is a risk to halt the Apache.
This allowed very powerful vanity-urls and redirects. It could also be used for filter-rules, etc.
Hi
you have to write rewrite rule in your Server httpd file :
this will help mod_rewrite - Apache HTTP Server Version 2.2
OR you can do in AEM by writing jsp.
http://www.aemcq5tutorials.com/tutorials/implement-301-302-redirect-aem/
More AEM/CQ5 SEO Best Practices: Redirects, Vanity URLs, and XML Sitemaps | Olson Digital
Hope these will Help!
Thanks
Views
Replies
Total Likes
Yes, I understand that I could manually add redirects in Apache, but these are redirects that are coming from the publisher, and managed from authoring. So I need them to invalidate and cache just like normal pages do...
Views
Replies
Total Likes
I didn't get what are you trying to do.if you want to invalidate the dispatcher cache please look this
Views
Replies
Total Likes
Before the dispatcher supported vanity urls, it was a common approach to generate a parts of the apache config dynamically on the publisher.
Therefore on the Apache each virtual-host defintion contained an optional include for a dynamically generated config-snippet. On the publisher was a servlet - which generated these config snippets (typically a lot of mod_rewrite rules for vanity-urls and redirects). A cron-job on Apache (= dispatcher) server called the servlet every 10 minutes, placed the generated configuration into the right place and made the Apache to reload the configuration (soft restart = no downtime). Nicer solutions generated a zip-file cointaining all configuration-snippets in a single archive. Also the cron job should let the Apache check the syntax of the configuration first. Otherwise there is a risk to halt the Apache.
This allowed very powerful vanity-urls and redirects. It could also be used for filter-rules, etc.
Hi Tim,
Could you please let me know if you were able to reach a solution for this? I am facing the same scenario wherein I need to cache the redirect responses from publishers so that the request does not always got to publish and is redirected from apache itself. If you were able to implement it, could you please let me know how did you implement it? I will appreciate it.
Thanks
Could you explain more details about the use case? Do you mean that a server side redirect happens via source code and that doesn't get cached by apache/dispatcher? I want to understand the entire request/response life cycle before throwing out couple of options to try. Hope that makes sense.
Views
Replies
Total Likes
Thanks for your response Gaurav. The user case is to set up a redirect on a page - not at apache level but at AEM level( via the page properties redirect field) so that this is authorable; so that when first request from browser comes, it hits publish and is redirected, but the next time the request comes from browser, it does not go to publish every time and it gets redirected from apache/dispatcher itself. so somehow apache/dispatcher knows about the redirect and is not sending the request every time to publisher. The user case is to reduce hits on publisher and keep the redirect non-technical user manageable(via page properties) and not at apache. Let me know if you understand it and have any option in mind.
Views
Replies
Total Likes
Did you get a chance to check vanityurls configuration in dispatcher? Per my understanding that should serve the purpose unless you have concerns or specific requirements.
Views
Replies
Total Likes
vanity urls are not redirects, right? vanity url will give me a page in aem if I the browser request is a or b or c
it will not redirect a url /e from browser to url /f
is the situation clear? do you have any other option in mind?
Views
Replies
Total Likes
You are correct if you talk about vanity urls in general but in AEM, you could achieve both use cases - resolution and redirection as applicable per requirement.
Try below configuration & see it yourself. If you turn on redirect checkbox, it adds sling:redirect property on the content page i.e. it becomes a server side redirect maintained by content author. Use /vanity_urls and /filter configuration in dispatcher and you should be good.
First request would go to publish server for redirection if its not cached and subsequent requests would be resolved by dispatcher itself to redirect and serve the cached content from dispatcher.
1) Configure vanity url in content page and activate
2) Configure /vanity_urls and /filter in dispatcher - Configuring Dispatcher
3) Download vanity urls component from package share and install it on publish server - https://www.adobeaemcloud.com/content/marketplace/marketplaceProxy.html?packagePath=/content/compani...
4) Test your use case and validate from dispatcher logs
I had tested the same in the past and I think it would work fine for your requirement. I can find dispatcher logs to share, if you are interested.
Views
Replies
Total Likes
thanks gauravb10066713, will try and post results/finding here in some time
Views
Replies
Total Likes
Views
Likes
Replies
Views
Like
Replies