[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041485#comment-16041485
]
Alexander Klimetschek edited comment on SLING-848 at 6/7/17 7:34 PM:
---------------------------------------------------------------------
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered).
Although I think it's still a problem of mixing URLs (where these parameters
come in) and the resource namespace, which came in by sharing the same
implementation (getResourceInternal) between resolve() and getResource(), while
it should probably be separated, so the parameter parsing happens for resolve()
only and other means given to retrieve things with parameter if you are a
client using getResource() semantics.
was (Author: alexander.klimetschek):
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered). Although I think it's still a problem of mixing URLs (where these
parameters come in) and the resource namespace, which came in by sharing the
same implementation (getResourceInternal) between resolve() and getResource(),
while it should probably be separated, so the parameter parsing happens for
resolve() only and other means given to retrieve things with parameter if you
are a client using getResource() semantics.
> Support getting versioned resources by using uri path parameters
> ----------------------------------------------------------------
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR, ResourceResolver
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
