[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16040505#comment-16040505
]
Roy T. Fielding commented on SLING-848:
---------------------------------------
Note that the semicolon-delimited syntax for path segment parameters was
defined in RFC1808 because I wanted a reserved syntax to support versions.
These parameters are supposed to be supplied at the end of a path segment, not
arbitrarily in the middle. They are not specifically defined in RFC3986 because
they are not needed for the generic syntax (scheme-independent parsing), but
semicolons are reserved for this purpose. In other words, a path that contains
a semicolon is supposed to be percent-encoded if it is not being used as a
parameter delimiter. An "=" is not necessary (e.g., VMS files used a name;NN
syntax).
Of course, that is not going to help us for existing deployments if we are not
automatically percent-encoding pathnames containing ";". We should have been
doing that all along.
I think the problem here is that the resolver is assuming that ";" indicates
path parameters and then removes them from the path resolution. What it should
be doing is either manage the segment names properly (meaning that a
non-encoded ";" is impossible) or be smarter about matching the resource
resolution so that ";" is allowable in unencoded form. IOW, what Alex said
above.
Also, filename extensions do not need to be at the end of path segments, and I
certainly hope we aren't using single-quotes around parameter values because
that isn't supported by any syntax.
> 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)
