[
https://issues.apache.org/jira/browse/SLING-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14613417#comment-14613417
]
Dirk Rudolph commented on SLING-4856:
-------------------------------------
>From my point of view there are two possible solutions:
1. Proper handling of not normalised paths in {{resolveInternal}}
- Extend {{ResourceUtil#normalize(String)}} to replace "//" by single slash
- Call {{ResourceUtil#normalize(String)}} on the path passed to
{{resolveInternal}}
2. Logging of not normalised result of applied mapping
- Add a method {{ResourceUtil#isNormalized(String)}}
- if log level is warning or higher call it after the mapping has been applied
and log a warning if it returns false
What do you think? I would volunteer to provide a patch and related test cases
for that.
> 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)
