This also does not seem to be 100% correct.
Just think about the following example:

There is a resource named "/a/b.c". Then the decomposition is as follows:

For "/a/b.c.html" the resource path would be "/a/b.c" and the extension would 
be "html", selectors would be null and suffix null.
For "/a/b.c/d" the resource path would be "/a/b" and the extension would be 
"c", selectors would be null and suffix "/d".
For "/a/b/c.html/test" the resource path would be "/a/b/c" the extension would 
be "html", selectors would be null and the suffix would be "/test"

So basically we have to distinguish between existing and non existing resource 
paths:

For existing paths, the resource path is the longest match (incl. mapping 
rules) where the next character is either a dot or it is the full request url.
Otherwise (for non-existing path) the separation is done at the first dot in 
the request url which splits resource path (non-existing) from the rest.

Am I correct with that assumption?
Thanks,
Konrad


> On 19 Sep 2016, at 11:22, Konrad Windszus <konra...@gmx.de> wrote:
> 
> I would like to extend the documentation in 
> https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html
>  a bit.
> 
> Basically for the Resource Path section it says:
> 
> Resource Path - The longest substring of the request URL such that the 
> resource path is either the complete request URL or the next character in the 
> request URL after the resource path is a dot (.).
> 
> I would like to modify that to:
> 
> Resource Path - The longest substring of the request URL pointing to an 
> existing resource (taking into account any resource mapping rules) such that 
> this part is either the full request URL or the next character in the request 
> URL after the resource path is a dot (.). 
> Without knowing the repository structure it is impossible to say which part 
> of the request URL is the resource path, because the resource path does not 
> necessarily end with the first dot (.) in the request url, as resource names 
> itself and therefore the resource path as well may contain dots (.). 
> Therefore it is impossible to tell just by looking at the request URL string 
> how it is gonna be decomposed by Sling.
> 
> This is IMHO an important aspect and should be explicitly mentioned on the 
> page 
> https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html
> 
> Is everyone fine with that change?
> Konrad
> 
> P.S. This change is triggered by the PR 
> https://github.com/apache/sling/pull/172 which incorrectly assumes that the 
> first dot separates the resource path from the rest.

Reply via email to