Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Caching Redirect Responses With Dispatcher?

Avatar

Level 3

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

1 Accepted Solution

Avatar

Correct answer by
Level 1

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.

View solution in original post

11 Replies

Avatar

Level 3

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...

Avatar

Level 5

I didn't get what are you trying to do.if you want to invalidate the dispatcher cache please look this

Invalidating Cached Pages From AEM - docs.adobe.com

Avatar

Correct answer by
Level 1

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.

Avatar

Level 4

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

Avatar

Level 10

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.

Avatar

Level 4

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.

Avatar

Level 10

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.

Avatar

Level 4

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?

Avatar

Level 10

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.

1665912_pastedImage_0.png

Avatar

Level 4

thanks gauravb10066713, will try and post results/finding here in some time