URL redirecting back to the parent page | Community
Skip to main content
V
vchanwalast5542
Level 2
March 19, 2021
Solved

URL redirecting back to the parent page

  • March 19, 2021
  • 1 reply
  • 1151 views

Hello all,

Scenario: https://www.domain.com/content/en-us/we-retail/men.html

In the above URL if I add (.) before men, then the content on the page is https://www.domain.com/content/en-us/we-retail.html 

but the URL is still remaining as https://www.domain.com/content/en-us/we-retail/.men.html
Please suggest how I can block the URL with (/.) before men, so that it will show up the 404 error.

 

Thanks in advance!  

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Asutosh_Jena_

Hi @vchanwalast5542 


As part of the Resource Resolution step, the client request URI is decomposed into the following parts:

  • Resource Path - For existing resources the resource path is the longest match pointing to a resource where the next character is either a dot (.) or it is the full request URI. Otherwise (for a path not matching any existing resource) the resource path ends at the first dot (.) in the request url.
  • Selectors - If the first character in the request URL after the resource path is a dot (.), the string after the dot up to but not including the last dot before the next slash character or the end of the request URL comprises the selectors.
  • Extension - The string after the last dot after the resource path in the request URL but before the end of the request URL or the next slash after the resource path in the request URL is the extension.
  • Suffix - If the request URL contains a slash character after the resource path and optional selectors and extension, the path starting with the slash up to the end of the request URL is the suffix path. Otherwise, the suffix path is empty.

In your case when you are requesting for https://www.domain.com/content/en-us/we-retail/.men.html Sling resolution happens and it finds /content/en-us/we-retail as the Resource Path and men is considered as the selector. So it serves the content of we-retail resource with 200 status without changing the URL. This is the default behaviour of sling and cannot be blocked at either author/publish instance.

 

You will need to apply apache redirects at the dispatcher to return 404 in this case. Please see the below redirect rule which will take care of the use case:

RewriteCond %{REQUEST_URI} (.*)\/\.(.*)\.html
RewriteRule (.*) - [R=404,L]

 

For details regarding Sling Resolution please refer the below article:
https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html

 

Hope this helps!
Thanks!

1 reply

Asutosh_Jena_
Community Advisor
Asutosh_Jena_Community AdvisorAccepted solution
Community Advisor
March 20, 2021

Hi @vchanwalast5542 


As part of the Resource Resolution step, the client request URI is decomposed into the following parts:

  • Resource Path - For existing resources the resource path is the longest match pointing to a resource where the next character is either a dot (.) or it is the full request URI. Otherwise (for a path not matching any existing resource) the resource path ends at the first dot (.) in the request url.
  • Selectors - If the first character in the request URL after the resource path is a dot (.), the string after the dot up to but not including the last dot before the next slash character or the end of the request URL comprises the selectors.
  • Extension - The string after the last dot after the resource path in the request URL but before the end of the request URL or the next slash after the resource path in the request URL is the extension.
  • Suffix - If the request URL contains a slash character after the resource path and optional selectors and extension, the path starting with the slash up to the end of the request URL is the suffix path. Otherwise, the suffix path is empty.

In your case when you are requesting for https://www.domain.com/content/en-us/we-retail/.men.html Sling resolution happens and it finds /content/en-us/we-retail as the Resource Path and men is considered as the selector. So it serves the content of we-retail resource with 200 status without changing the URL. This is the default behaviour of sling and cannot be blocked at either author/publish instance.

 

You will need to apply apache redirects at the dispatcher to return 404 in this case. Please see the below redirect rule which will take care of the use case:

RewriteCond %{REQUEST_URI} (.*)\/\.(.*)\.html
RewriteRule (.*) - [R=404,L]

 

For details regarding Sling Resolution please refer the below article:
https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html

 

Hope this helps!
Thanks!

    Terms & ConditionsAccessibility statement

    Loading footer...