I now raised two more PR just to streamline the documentation (without touching the implementation).
1) https://github.com/apache/sling-org-apache-sling-api/pull/69 2) https://github.com/apache/sling-site/pull/249 Please have a look. Thanks, Konrad > On 3. Nov 2025, at 15:07, Konrad Windszus <[email protected]> wrote: > > 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 >> >
