[jira] (SLING-4856) Resource resolution fails when mapped path is not normalised

["Dirk Rudolph (Jira)" <ji...@apache.org>]

    [ 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)