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.
