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
