[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670266#action_12670266
]
Felix Meschberger commented on SLING-848:
-----------------------------------------
Yes, according to rfc3986
/content/home;v=1.0/tobi;v=1.5
would be perfectly valid. But we won't support it, since this leads into areas
which are too complicated to grasp and which can almost not be described. For
this reason, we define, that the ;v= URI parameter is only recognized and used
on the last segment.
Now, for the location of the ;v= specification. The intened location is of
course to be at the end, as in
/content/home/tobi.html;v=1.5
If we would have Resource.getPath() include the ;v= we would of course also
have to support things like
/content/home/tobi;v=1.5.selector.html
You are right, that this is neither nice nore very logic, though not
necessairily violating the spec.
Maybe we should think about this some more.
> btw: i think the "component" of this issue is wrong.
Probably yes, but this is the only component available currently for treating
ResourceResolver issues. We should probably create another one -- also in light
of the proposed extension of the ResourceResolver infrastructure.
> 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: JCR Resource
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
>
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
