[ https://issues.apache.org/jira/browse/SLING-4856 ]
Dirk Rudolph deleted comment on SLING-4856:
-------------------------------------
was (Author: diru):
Another area where this happens is with /etc/map entries that use
{{sling:match}}, for example:
{code}
/etc/map/http/my-site
+ sling:math = "domain.\\d.+"
+ sling:internalRedirect="[/,/content/domain]"
{code}
In this case the map entry is "partially" correct, meaning it resolves well for
paths in /content/domain but not for paths in /, for example:
{code}
http://domain/us/en.html => /content/domain/us/en.html (if
/content/domain/us/en exists)
http://domain/etc.ext/suffix.js => //etc.ext/suffix.js (if neither /etc nor
/contnet/domain/etc exist)
{code}
> 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)
