Hi, The most relevant source code in this context is probably: https://github.com/apache/sling-org-apache-sling-engine/blob/229091497ffcfcb43ebcce659f0cc36b007ad5a6/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L57-L102
So actually the logic of RequestPathInfo and ResourceMetadata (https://github.com/apache/sling-org-apache-sling-api/blob/master/src/main/java/org/apache/sling/api/resource/ResourceMetadata.java) correlate. Konrad > On 3. Nov 2025, at 14:15, Konrad Windszus <[email protected]> wrote: > > Hi Jörg, > >> On 3. Nov 2025, at 13:51, Jörg Hoh <[email protected]> wrote: >> >> Hi, >> >> For that question "What is the resource path if the resource is non >> existent?" I would rely on the existing implementations; and that is indeed >> quite inconsistent (for example >> ResourceResolver.getResource("/non/existent/resource") returns null). >> So that problem only applies to the Request API. > > I am not talking about differences between ResourceResolver.getResource() vs > ResourceResolver.resolve(…) which are documented clearly in the Javadoc in my > opinion. > This is just about the path of the request bound resource (never null, uses > resolve under the hood). > >> >> In the case of requests to non-existing resources I would use a straight >> forward approach and not try to parse any selectors,extension and suffixes, >> as that could give a false sense that indeed some extensions and suffixes >> were provided, even if we cannot say that for sure. So I would clarify the >> documentation in a sense, that these rules only apply to existing >> resources, and that for the case of non-existing resources the full url is >> taken a path (and no selectors, extension and suffixes are calculated). > This is not how the implementation works right now and I fear this would be > quite dangerous how it is changed. > Rather selector/extension/suffix is always populated from a heuristics (and > duplicates info from the resource path for non-existing resources). >> >> That leaves the question of errorhandlers which rely on an extension to >> derive the right way to react on that. > Again, as said before, this is probably not worth to change it. > So I would rather propose that we > > 1) clarify that resource path for non-existing resources use the full request > URI (this requires fixing > https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html, > I already fixed > https://github.com/apache/sling-org-apache-sling-api/commit/0f3a152fe9999fd276910c10d6a5ac39acf1f405). > The documentation currently incorrectly states "for a path not matching any > existing resource) the resource path ends at the first dot (.) in the request > url." > > 2) then decide on what to do with > https://github.com/apache/sling-org-apache-sling-api/blob/0f3a152fe9999fd276910c10d6a5ac39acf1f405/src/main/java/org/apache/sling/api/resource/ResourceMetadata.java#L315 > and > https://github.com/apache/sling-org-apache-sling-api/blob/0f3a152fe9999fd276910c10d6a5ac39acf1f405/src/main/java/org/apache/sling/api/resource/ResourceMetadata.java#L289 > with regards to javadoc, because what is currently states is not reflecting > reality either. > I don’t yet have a good solution for this. Anyone else with a proposal how > those two should look like for non-existing resources? > > Thanks, > Konrad > >> >> Jörg >> >> >> Am Sa., 1. Nov. 2025 um 18:14 Uhr schrieb Konrad Windszus <[email protected]>: >> >>> Hi, >>> The main question which should be answered first is what should be the >>> resource path. >>> Is it " /some/nonexisting/resource” (so everything till the first dot) or >>> rather "/some/nonexisting/resource.selector1.selector2.extension/suffix” as >>> it is now? >>> That has an impact on RequestPathInfo and Resource.getPath(). >>> Contrary to the documentation in >>> https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html >>> the resource path concatenated with selectors, extension and suffix does >>> not always yield the URL request path right now. >>> Konrad >>> >>> >>>> On 31. Oct 2025, at 20:35, Jörg Hoh <[email protected]> >>> wrote: >>>> >>>> Hi Konrad, >>>> >>>> so if I understand you correct, the documentation suggests that >>>> SlingHttpServletRequest.getResource().getResourceMetadata() should return >>>> these values: >>>> * sling.resolutionPath = /some/nonexisting/resource >>>> * sling.resolutionPathInfo = .selector1.selector2.extension/suffix >>>> >>>> but currently sling.resolutionPath >>>> = some/nonexisting/resource.selector1.selector2.extension/suffix is >>>> returned. >>>> I would change the implementation and for non-existing paths >>>> sling.resolutionPathInfo should not be present in the map. This would be >>>> consistent with the implementation of the other ways dealing with >>>> non-existing resources, and also adhere to the documentation. >>>> >>>> Jörg >>>> >>>> >>>> >>>> Am Fr., 31. Okt. 2025 um 17:48 Uhr schrieb Konrad Windszus < >>> [email protected] >>>>> : >>>> >>>>> Hi, >>>>> We have some inconsistency with regards to resource paths and >>> nonexisting >>>>> resources in implementation and documentation. >>>>> >>>>> For a request path >>>>> "/some/nonexisting/resource.selector1.selector2.extension/suffix" the >>>>> following is returned for SlingHttpServletRequest.getRequestPathInfo >>> (in a >>>>> Sling Servlet Filter with scope “REQUEST") >>>>> >>>>> 1) getResourcePath(): >>>>> "/some/nonexisting/resource.selector.extension/suffix” >>>>> 2) getExtension(): “extension” >>>>> 3) getSelectorString(): “selector1.selector2” >>>>> 4) getSuffix(): “/suffix” >>>>> >>>>> SlingHttpServletRequest.getResource().getPath() returns >>>>> "/some/nonexisting/resource.selector.extension/suffix” as well. >>>>> SlingHttpServletRequest.getResource().getResourceMetadata() returns >>>>> "{sling.parameterMap={}, >>>>> >>> sling.resolutionPath=/some/nonexisting/resource.selector1.selector2.extension/suffix, >>>>> sling.resolutionPathInfo=.selector1.selector2.extension/suffix}” >>>>> (Due to >>>>> >>> https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/e7f0d0ad2c4a32e8603285f242920f4fb66aa38d/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L463-L479 >>>>> ) >>>>> The resource metadata violates this contract: >>>>> >>>>> "The value of this property concatenated to the value of the {@link >>>>> #RESOLUTION_PATH sling.resolutionPath} property returns the original >>>>> request URI leading to the resource." >>>>> ( >>>>> >>> https://github.com/apache/sling-org-apache-sling-api/blob/0f3a152fe9999fd276910c10d6a5ac39acf1f405/src/main/java/org/apache/sling/api/resource/ResourceMetadata.java#L60 >>>>> ) >>>>> >>>>> Also at >>>>> >>> https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html >>>>> we state >>>>> >>>>> "Resource Path - For existing resources the resource path is the longest >>>>> match (also considering its mappings) pointing to a resource where the >>> next >>>>> character is either a dot (.) or it is the full request URI. Otherwise >>> (for >>>>> a path not matching any existing resource) the resource path ends at the >>>>> first dot (.) in the request url. The exact logic for retrieving the >>>>> resource path is implemented at >>>>> ResourceResolver.resolve(HttpServletRequest, String) called from >>>>> org.apache.sling.engine.impl.request.RequestData.initResource() with the >>>>> 2nd argument being the request path. “ >>>>> >>>>> What is wrong? Doc or Impl? >>>>> Thanks for any input. >>>>> Konrad >>>> >>>> >>>> >>>> -- >>>> https://cqdump.joerghoh.de >>> >>> >> >> -- >> https://cqdump.joerghoh.de >
