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
