Common etc map internal redirect shorting rule for .html and without .hml pages

[Mohanasundaram]

Hi,

Currently i am having two separate shorting rule in etc mapping for .html and without .html page.

/content/site/en/folder/home/(.*).html

/content/site/en/folder/home/(.*)

I need this as common rule like single sling:internalRedirect rule to fix for both .html and without .html pages.

Thanks,

Mohan

[markus_bulla_adobe]

Hi @Mohanasundaram!

It is recommended to use URLs with an extension (usually ".html") when it comes to AEM. Main reason for this is that AEMs Dispatcher will not cache requests without extension.

You can still omit extensions for your end users. My recommendation is to handle that on an Apache httpd / Dispatcher level using mod_rewrite rules. Rewrite rules can be setup to add the ".html" extension for further internal processing (without exposing this anywhere to the end user), thus requests being handled by the Dispatcher and (potentially) by the AEM publish tier will already contain the extension.

To be consistent, you will also need a Sling rewriting configuration to make sure all links rendered by AEM to the source code of your website will be stripped of the ".html" extension.

This article outlines the required steps to achieve URLs without extensions.

There is another article going through different options and components on the AEM stack that are/can be involved in URL shortening and getting rid of extensions.

Hope that helps!

[Mohanasundaram]

Hi @markus_bulla_adobe 

Thanks for the response.

As per the best practice, yes we need to  use .html page. But authoring end users browse and add some pages URLs. Those page URLs created from authoring are not contain .html extension.  So i want to short the both .html and not html URL in common etc/map rule.

Thanks,

Mohan

[markus_bulla_adobe]

Hi @Mohanasundaram!

So my understanding is:

When your content authors are adding links to a component, the resulting link does not contain the required ".html" extension. Is that right?

In that case, there seems to be a flaw in your implementation of the link rendering.

In AEM, internal links to other pages are stored as a path to the page on the repository (e. g. /content/weretail/home) without an extension. When rendering such a link as part of your component implementation, you need to make sure to run the reference through the externalizer. That way, it will make sure to apply configured mappings and also add the extension.

If my understanding is correct, I highly recommend to fix the link rendering rather than trying to solve the symptom through additional mappings and rewriting.

Hope this helps!

[Jagadeesh_Prakash]

@Mohanasundaram  Why can't you use dispatcher rule to redirect the html or no html to a single rule ? Some thing like below

# Redirect for URLs with .html extension to without .html extension Redirect 301 { /content/(.*\.html) } /content/$1 # Redirect for URLs without .html extension to with .html extension Redirect 301 { /content/(?!.*\.html)(.*) } /content/$1.html

[Mohanasundaram]

Thanks for the response.

Yes . we have request from client need to implement under etc map without using dispatcher. That's why looking for etc map side.

Any thoughts from etc map side?

[markus_bulla_adobe]

Sticking to a specific technical solution as part of a (client) requirement is usually not a very good way to approach solution design. While /etc/map does have it's use cases, handling duplicate links to the same set of pages/content does very much sound like a flawed design of link management rather than a use case for url mapping.

This indicates that you are most probably trying to cure a symptom (links without extensions) with an inadequate medication (/etc/maps) - instead of solving the underlying issue (proper externalization and link rendering).

I would highly recommend to get that sorted rather than implementing workarounds and adding additional complexity.

[MohanasundaramMo]

Thanks for the response all. Let me try with externalization and link checker rendering.

[Sudheer_Sundalam · Accepted solution]

@MohanasundaramMo ,

Here is a simple static java method you may use across the application to validate the URL and decide to append .html or not.

This method covers the below scenarios

• If the URL is external(meaning starting with http/https)
• if the url is a DAM asset path
• If the url ending with .html already
• if the url is ending with ".pdf" (for special cases)

Hope this helps!

public static String updateUrl(String url) {
		if (url == null) {
			return null;
		}
		  try {
			URI uri = URI.create(StringUtils.replace(url, " ", "%20"));
			
			// No host and no scheme?  Its a local url.  We may have to modify it.
			if (uri.getScheme() == null && uri.getAuthority() == null) {
				StringBuilder result = new StringBuilder();
				if (!StringUtils.isBlank(uri.getPath())) {
					result.append(uri.getPath());
					if (!uri.getPath().startsWith("/content/dam") && !uri.getPath().contains(".html") && !uri.getPath().endsWith(".html") && !uri.getPath().endsWith(".pdf")) {
						result.append(".html");
					}
				}
				if (uri.getQuery() != null) {
					result.append(String.format("?%s", uri.getQuery()));
				}
				if (uri.getFragment() != null) {
					result.append(String.format("#%s", uri.getFragment()));
				}
				return result.toString();
			} 
			
			return uri.toString();
		} catch (IllegalArgumentException e) {
			log.warn(String.format("Bad Url [%s]", url), e);
		}
		  return url;
	  }

[kautuk_sahni]

@Mohanasundaram Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.