Background: Redirect Map Manager vs. Redirect Manager in AEMaaCS

Previously, ACS Commons Redirect Map Manager was unsupported on AEMaaCS, limiting options for handling redirects. As a workaround, customers needed to use ACS Commons Redirect Manager, which came with several challenges:

• Reliance on Dispatcher Rules: Redirect Manager required that all redirect requests pass through the Dispatcher’s rules to reach the AEM publishers, where Redirect Manager rules could then be executed. This dependency on Dispatcher configurations often led to complications. Only requests meeting specific Dispatcher criteria reached the publisher, and requests blocked by earlier Dispatcher rules (e.g., rules for file types or specific paths) would bypass the publisher entirely, causing some redirects to fail.
• Potential for Conflicting Rules: Dispatcher has its own rewrite rules, which can sometimes interfere with redirects set in Redirect Manager. If a Dispatcher rewrite rule processes a request before it reaches Redirect Manager, it can override the redirect, leading to unexpected behaviors or even redirect loops. This makes troubleshooting and coordinating rules more challenging.
• Increased Maintenance and Complexity: Coordinating Dispatcher rules with Redirect Manager required ongoing adjustments to ensure consistency across both levels. This setup added maintenance overhead, as new rules or configurations in the Dispatcher required verification to avoid interfering with existing redirects.

With AEM version 18311 and the support for ACS Commons Redirect Map Manager, these limitations are greatly reduced. Redirect Map Manager now allows redirect processing to be handled entirely at the edge by the Dispatcher, minimizing reliance on AEM publishers and aligning with Adobe’s best practices for cloud environments.

Key Benefits of the New Setup

1. Offloading Redirects to the Dispatcher

With ACS Commons Redirect Map Manager, redirect processing is managed at the Dispatcher level, reducing the need for requests to be handled by publishers. This shift improves performance and scalability:

• Previous Configuration with Redirect Manager: The first request for a redirect had to be processed by the AEM publisher, placing load on the AEM instance until CDN caching took effect. For high-traffic sites, this dependency on the publisher created potential performance bottlenecks.
• New Configuration with Redirect Map Manager: Redirects are processed directly by the Dispatcher, with CDN caching supporting subsequent requests. This reduces publisher load and improves response times, allowing for smoother handling of large-scale redirects.

2. Simplified Management with Fewer Conflicts

Redirect Map Manager reduces the likelihood of conflicts with Apache’s Dispatcher rewrite rules:

• Better Coordination with Dispatcher Rules: With redirect processing fully managed at the Dispatcher, Redirect Map Manager rules are less likely to conflict with existing rewrite rules, eliminating the need to pass through complex Dispatcher configurations to reach the publisher.
• Reduced Complexity: Redirect Map Manager’s edge-based handling simplifies redirect rule management, enabling more consistent behavior and reducing the need for Dispatcher-publisher coordination.

3. Greater Flexibility for Business Users

This update provides a more accessible and flexible redirection setup for business users who need to control redirects but may lack access to development pipelines:

• User-Friendly Management Interface: ACS Commons Redirect Map Manager offers an intuitive interface within AEM for managing redirects. Business users can easily create, edit, and organize large numbers of redirects without requiring deployments or extensive pipeline configurations.
• Scalability for Large-Scale Operations: Redirect Map Manager supports thousands of redirects directly within AEM, making it ideal for business-driven redirect management at scale.

How to Configure Pipeline-Free URL Redirects with Redirect Map Manager

Setting up pipeline-free redirects with the ACS Commons Redirect Map Manager in AEMaaCS is straightforward:

1. Define Redirect Maps: In the managed-rewrite-maps.yaml file, specify paths to redirect files stored in the publish repository.
2. Manage Redirects in Redirect Map Manager: Use the Redirect Map Manager’s user interface to set up and organize redirect mappings. The tool’s UI allows direct integration with Dispatcher for a streamlined process.
3. Configure Apache RewriteMap:
   • Set up the RewriteMap directive in Apache to ensure optimal redirect caching and performance at the Dispatcher level. Here’s a sample configuration:

   1 2 3

   RewriteMap map.foo dbm=sdbm:/tmp/rewrites/my.map RewriteCond ${map.foo:$1} !"" RewriteRule ^(.*)$ ${map.foo:$1|/} [L,R=301]

For a deeper dive into this feature, visit Adobe’s full article: Pipeline-Free URL Redirects.

Visit the official ACS Commons Redirect Map Manager Page.

Conclusion

The introduction of ACS Commons Redirect Map Manager support in AEMaaCS marks a significant improvement in URL redirection management. By handling redirects at the Dispatcher, this feature enhances performance, reduces complexity, and minimizes publisher load, all while aligning with Adobe’s best practices for AEM Cloud environments.

With these changes, managing large-scale redirects in AEMaaCS becomes more efficient, flexible, and scalable, making it easier for teams to maintain high performance and consistency across their AEM implementations.

The post Pipeline-Free URL Redirects & ACS Commons Redirect Map Manager Now Supported on AEMaaCS appeared first on Sourced Code.

1. Cacheable Requests

The Dispatcher can cache a URL if it meets the following criteria:

• Configured to be Cacheable: The request is explicitly configured as cacheable in the Dispatcher configuration.
• Plain GET Request: The request is a simple HTTP GET request.
• URL with Extension: The request URL must include an extension, such as .html.

2. Non-Cacheable Requests or Responses

There are several scenarios where requests or responses cannot be cached by the Dispatcher:

• Denied by Configuration: Requests that are denied caching by specific configuration settings, such as paths, patterns, or MIME types.
• Special Headers:
  • Responses that include a “Dispatcher: no-cache” header.
  • Responses that include a “Cache-Control: no-cache” or “Cache-Control: private” header.
  • Responses that include a “Pragma: no-cache” header.
• Request with Query Parameters: Any request that contains query parameters.
• URL Without Extension: URLs that do not have an extension cannot be cached.
• URL with Suffix Without Extension: URLs that have a suffix lacking an extension.
• Non-200 Status Code: Responses that return a status code other than 200.
• POST Requests: HTTP POST requests cannot be cached as they typically involve changes to the server state.

3. Conclusion

Understanding which requests and responses are cacheable is crucial for optimizing the performance of your AEM instance. By ensuring that only appropriate content is cached and by configuring your Dispatcher settings correctly, you can improve both the speed and reliability of your website. Keep these rules in mind to ensure effective caching with AEM Dispatcher.

The post AEM Dispatcher Uncacheable Requests appeared first on Sourced Code.

1. URLs Without Extensions Are Not Cached

In AEM, URLs must always have an extension to be cacheable by the Dispatcher. While you can serve URLs without extensions in AEM, these URLs will not be cached by the Dispatcher, leading to potential performance issues.

2. Examples

Cacheable URL:

This URL includes an extension (.html) and is therefore cacheable by the Dispatcher.

Non-cacheable URL:

This URL lacks an extension and will not be cached by the Dispatcher. However, if you use the [PT] pass through to internal AEM resource ending with .html, it will be cached.

3. Using Apache [PT] Pass Through as a Fallback

To handle URLs without extensions and ensure they are still processed correctly, you can use Apache’s [PT] (Pass Through) flag. This allows the URL to be passed through to the backend server, appending .html to the request, thereby enabling it to be cached by the Dispatcher.

Example Apache Configuration

Consider the following common dispatcher configuration to handle extensionless URLs:

With this configuration, when a domain like http://domain.com/en/home is hit, it will actually map to:

For example, if ${CONTENT_FOLDER_NAME} is wknd, the URL http://domain.com/en/home would map to:

This allows the Dispatcher to cache the resource correctly.

4. Additional Examples

Original URL:

Rewritten URL with [PT]:

Original URL:

Rewritten URL with [PT]:

In both examples, the extensionless URLs are mapped to URLs ending in .html, making them cacheable by the Dispatcher.

5. Conclusion

To ensure your pages are cached by the Dispatcher, always add extensions to your URLs. Some may argue that having extensions in URLs could negatively affect SEO rankings. However, an uncached page can lead to slow loading times, which can hurt your SEO rankings even more.

By following these guidelines and using Apache [PT] rules as a fallback, you can optimize your AEM Dispatcher caching strategy and improve the performance and reliability of your AEM instance.

The post Caching AEM Pages with Extensionless (.html) appeared first on Sourced Code.

After some research, I found that the issue was related to the access permissions of the file in question. To resolve the problem, I ran the command “chmod 777 conf.d/dispatcher_vhost.conf” on my Mac machine. This successfully allowed me to proceed with my local AEM setup.

But what exactly is “chmod 777”?

In Linux and Unix-based operating systems, “chmod” stands for “change mode” and is used to adjust the read, write, and execute permissions of a file or directory. The number “777” is a three-digit code called the “file mode” or “permission mode”. It represents the permissions for the owner of the file, the group the file belongs to, and all other users.

Here are the details about the 777 permission:

7 is the permission for owner
7 is the permission for group
7 is the permission for others (users)
Each digit in the file mode is a sum of the values for the read (4), write (2), and execute (1) permissions. So, 777 means that the owner, the group, and other users all have full read, write, and execute permissions for the file or directory.

It’s important to note that chmod 777 is considered a very open permission, and is not recommended from a security standpoint. It’s generally better to use more restrictive permissions such as 644 for files and 755 for directories, which will still allow the owner to read and write to the file, but prevent others from making any changes. However, for local testing purposes, chmod 777 can be used.

The post error: immutable file ‘conf.d/dispatcher_vhost.conf’ has been changed! appeared first on Sourced Code.

This article is written while I had my development environment running, where the AEM publish server and dispatcher apache server are on the same system, similar setup to here. However, the understanding here will be valid for external servers setup.

1. How is the /dispatcher/invalidate.cache generated?

There’s no magic behind the /dispatcher/invalidate.cache endpoint. This endpoint is actually created by the AEM Dispatcher Module. When the Dispatcher Module is enabled on your web server’s VirtualHost the endpoint will be available. However, not anyone can be calling this endpoint where in the next section we will go through how to set up permissions for the this.

Example

2. How do we securely allow only specific IP addresses to make a flush cache request?

With a fresh installation of the dispatcher, utilising the dispatcher.any template, there will be a section called allowedClients (all configuration have been commented out in the default configs). The /allowedClients property defines specific clients that are allowed to flush the cache; globbing patterns are matched against the IP.

When the setup is complete, you are now able to make calls to the /dispatcher/invalidate.cache endpoint, for example, http://localhost:80/dispatcher/invalidate.cache. When configuring the Web Server on an external server, making sure that the AEM publish server is whitelisted from the dispatcher server, and the dispatcher.any file from the /allowedClients property is configured.

Example
As an example, we can configure the values here with localhost & 127.0.0.1.

3. How to configure a basic dispatcher flush agent on the AEM publish?

After when steps 1 & 2 from above is completed, we can go straight to our replication agents to publish to configure the dispatcher flush agent. It would be as simple as these simple steps below:

1. Visit the configuration page http://localhost:4503/etc/replication/agents.publish/flush.html.
2. Insert your valid URI in the configuration. (in my case, I will use http://localhost:80/dispatcher/invalidate.cache)
3. Test the connection to get a connection success status.
4. Enable the flush agent.
5. We are done.
6. Go ahead and activate a page from author to test this out.

When you activate a page from the author environment, your Web Server logs should show something like this :

Last Notes

Lastly, I just wanted to say that it is best practice to set up the dispatch flush agent on the publish server, as this will eliminate content race conditions; where the content has been successfully replicated to the publish instance, then a content flush is fulfilled.

The post How to Setup the AEM Dispatcher Flush Agent? appeared first on Sourced Code.