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
