mark Redirect Map Manager as enabled in AEM CS #274
Conversation
There was a problem hiding this comment.
With having two redirect features in place now in ACS AEM Commons (also https://adobe-consulting-services.github.io/acs-aem-commons/features/redirect-manager/index.html) there should be clarification when it is recommended to use which one. I currently fail to see the need for this solution, given that the CDN is caching the redirects from https://adobe-consulting-services.github.io/acs-aem-commons/features/redirect-manager/index.html (at least with AEMaaCS).
|
@kwin Trying to clarify the question you asked:
I think (please correct me if I'm wrong and/or I couldn't find) there RM does not explain why it got created even though RMM already existed, besides implicit rationale that at that time RMM was working only for on-prem/AMS but not AEMaaCS. Possibly there might be a need to explain somewhere why some users prefer not to have all requests for such AEM-controllable/editable/manageable "redirects" (but not only) never reach AEM publish tier, but rather to be handled at most at Apache HTTPD/dispatcher tier only (as dispatcher module is unable to cache 30x responses directly). Leaving even the request which would be (probably) redirected in the end not to be propagated to AEM publish tier, there are also scenarios where certain Apache HTTPD and/or request-specific properties or variables are to be evaluated before given decision what exact processing (so also possibly redirect) to make (e.g. header-based, cookie-based, geolocation-based etc). If variability domain of such decision key is large (so that Vary is not feasible through CDN for caching) and/or user of this functionality does not want it to be cached in CDN layer as a redirect, but a rewrite to a response with 200 OK should be made, then the most correct place in the stack (assuming previous prerequisites) is the Apache HTTPD / dispatcher tier in this scenario. Not sure if for non-AEMaaCS cases there is any comparison why RM or RMM should be used and for which scenario one is a better fit than the other. Maybe the potential user should decide if they like their request to go as far as to AEM publish tier for a decision, or would they prefer it to be processed in a tier earlier (Apache HTTPD/dispatcher) in which case it doesn't need to be a redirect in result per se, but rather mod_rewrite's rewrite (where redirect is just one of the possible options)? It is also worth to add the Purpose paragraph of RMM:
so even if historically the name is Redirect Map Manager, still in fact what it does it providing a way to steer Apache HTTPD rewrites from AEM, and redirect is just one of multiple ways rewrites might end up. |
|
For me the biggest downside of RMM is the additional complexity of pulling the rewrite map file from AEM, therefore I would currently state as a rule of thumb: Use RM if you have a CDN capable of caching 3xx responses, otherwise use RMM. |
|
@kwin There is some explanation for the downside you had expressed in:
Some users do not wish to have 3xx responses for some old or non-maintained any more links, some work around it with lots of RewriteCond+RewriteRule statements, some use static RewriteMap maps, but maintaining them requires changes in Apache HTTPD configuration each time - not all users want or (in the long run) can do it efficiently and timely - so editing them via AEM authoring while still being able to use the functionality done once in Apache HTTPD configuration for it (and further just changing the content on AEM side that it is using) is what they foresee (otherwise they would have already chosen RM but it's not 100% fit for their needs), hence enabling RMM on AEMaaCS as well (they way - at least from AEM-side functionality perspective - as it worked so far on-prem/AMS) is a way to go for them. Pulling rewrite map currently (for on-prem/AMS) might be indeed quite troublesome/low-level with cron, shell etc. for some, that is why for AEMaaCS it is meant to be as simple as possible - but so far it's still in Early Adopter Program phase to be opted-in - see https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/release-notes/release-notes/2024/release-notes-2024-5-0#apache-rewritemaps-early-adopter and ACS Commons' RMM is meant to be one of the multiple possible sources of map data for it exposed from AEM tier:
|
The motivation was to create an AEM tool, aware of the AEM features like content-aware configurations, etc. I also wanted it to be user-friendlier than RMM. I'm not saying RMM is not good, but I wouldn't recommend it as a go-to solution. And user acceptance of RM speaks for itself. There can be cases when you would want to redirect from HTTPd, but these are edge cases . Most times RM will work well. @kwin Now, when we have two redirect solutions having similar names it can be confusing. I wonder if it's a good idea to combine them into one, like, edit redirect rules in RM and have a way to compile them into the HTTPd format and use the same mechanism to push it to HTTPD. Regards, |
|
Hi @kwin , @YegorKozlov I think it's a bit unfortunate that ACS AEM Commons adopted 2 different solutions for a very similar usecase, and then even have their names very similar to almost identical... but now we have to live with it. Right now we are planning to add explicit support in AEM CS for the RMM, as it's a more convenient way to maintain redirects than having to add them into git and deploy them with a webtier pipeline. While serving redirects directly out of AEM might give you more flexibility, it's problematic regarding any kind of scaling. Serving them from the dispatcher (or even from the CDN) is much better. @YegorKozlov I like your approach to merge the 2 approaches into a single solution; especially if it could follow the approach of RM regarding the integration into dispatcher. |
|
I agree that we should merge the two by extending RM with the RMM capability (not the other way around) as maintenance is much easier with RM. @joerghoh Is there any restriction about the format of redirect map file (going beyond https://httpd.apache.org/docs/2.4/rewrite/rewritemap.html#txt) or the URL from which it should be served? |
|
@kwin The format is that "plain-text mapping file, containing one space-separated key/value pair per line" as described in https://httpd.apache.org/docs/2.4/rewrite/rewritemap.html#txt and additionally consumable by https://httpd.apache.org/docs/2.4/programs/httxt2dbm.html utility - with the constraints mentioned also in https://adobe-consulting-services.github.io/acs-aem-commons/features/redirect-map-manager/index.html#purpose e.g. "Note that Apache has an 1024 length limit for RewriteMap single entries." |
|
So my conclusion to this topic:
I just discussed with @krystiannowak offline, that the format specifier he provided could be considered as a version 1 of that interface, and that it should be possible to eventually create a version 2, which can support more features. And then the next steps would be:
|
|
related to ACS Commons milestone https://github.com/Adobe-Consulting-Services/acs-aem-commons/milestone/172 |
|
I would merge this PR by tomorrow EOB (Sept 27), as it would just officially document RMM to be supported on the AEM CS side. I think that every other question raised in this thread is a discussion on its own:
@kwin @YegorKozlov any objections? |
|
Merging this PR makes sense after a release containing the code changes, not before. Apart from that I agree. |
do you mean the AEM CS release supporting redirect maps? @joerghoh I don't mind merging this PR. |
cc: @davidjgonzalez @SachinMali @joerghoh @chaik @froesef