[
https://issues.apache.org/jira/browse/SLING-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated SLING-4856:
--------------------------------
Priority: Major (was: Minor)
> Resource resolution breaks selector string 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}
> 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 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)
