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.
Hope these will Help!
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...
1 person found this helpful
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.
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.
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.
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.
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.
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?
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=/conte nt/companies/public/adobe/pack…
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.
thanks gauravb10066713, will try and post results/finding here in some time