Dirk Rudolph created SLING-4856:
-----------------------------------
Summary: 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: Minor
*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
(v6.3.4#6332)
