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!
