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.
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).
That leaves the question of errorhandlers which rely on an extension to
derive the right way to react on that.
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
