[
https://issues.apache.org/jira/browse/SLING-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph resolved SLING-4856.
---------------------------------
Resolution: Cannot Reproduce
I cannot reproduce that anymore, it seems to work now.
I tried this with the following mapping entry instead
{code}
/etc/map/http/my-site
sling:math="domaing.\\d+"
sling:internalRedirect="[/,/content/domain]"
{code}
If I try to resolve an existing resource everything works as expected.
If I try to resolve a non-existing resource with that I get
{{//non-existing-resource.selector1.selector2.html}}, which is properly parsed
into
{code}
selectors = [selector1, selector2]
extension = html
{code}
The resourcePath however remains
{{//non-existing-resource.selector1.selector2.html}}
> Resource resolution fails when mapped path is not normalised
> ------------------------------------------------------------
>
> Key: SLING-4856
> URL: https://issues.apache.org/jira/browse/SLING-4856
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.1.14
> Reporter: Dirk Rudolph
> Priority: Major
>
> *Description*
> During resource resolution the resource metadata are populated with values
> used for the initialisation of the {{SlingHttpServletRequest}} in the
> {{{}SlingRequestProcessorImpl{}}}. The problem is that those metadata may be
> broken when there is a misconfigured mapping applied to the request path info.
> *How to reproduce*
> 1. Configure the {{ResourceResolverFactory}} to have a mapping
> {{{}/>/prefix{}}}.
> 2. Create a {{Resource}} /content/path/to/resource
> 3. Access the {{Resource}}
> 3 a) using /content/path/to/resource.selector1.selector2.html/suffix.html
> 3 b) using
> /prefix/content/path/to/resource.selector1.selector2.html/suffix.html
> _Expected result_
> - The path can be resolved to the {{Resource}} (/)
> - The selector string is selector1.selector2 (x)
> - The suffix is /suffix.html (/)
> _Actual result_
> In the second case (b) the selector string has a leading ".". Which causes
> the {{RequestPathInfo}} to return a {{{}String[3]{}}}, where the first entry
> is an empty {{{}String{}}}.
> *Details*
> This is caused by the following code in {{resolveInternal}}
> {code:java}
> final String path = resolutionPath.toString();
> final String pathInfo = absPath.substring(path.length());
> resource.getResourceMetadata().setResolutionPath(path);
> resource.getResourceMetadata().setResolutionPathInfo(pathInfo);
> {code}
> The problem is that in this special case the resolved path starts with a "//"
> and is therefor not properly normalised. As the resolution is working
> properly and the returned resource has its path normalised the length of
> resource path part in the absPath and resoultionPath differ by one. This
> causes resoultion path info to contain the last char of the resource path
> part of the absPath, which then causes wrong interpretation and extraction of
> the selector string from the resolution path info in the {{ResourceMetaData}}
> *Use case*
> In our current project based on AEM6 we use such a path prefix to use
> separated dispatcher farms for caching. We were able to fix the internal
> issue by properly configuring the prefix but as a user i would expect Sling
> to handle this misconfigured scenario either properly or at least log a
> warning that the mapped path is not normalised because debugging it was a
> little bit tricky.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
