[
https://issues.apache.org/jira/browse/SLING-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784902#action_12784902
]
Alexander Klimetschek edited comment on SLING-1218 at 12/2/09 5:07 PM:
-----------------------------------------------------------------------
Attaching patch that solves the issue by using the URI class from
commons-httpclient 3.1, which can accept unescaped uri strings, can update the
unescaped path part and properly return an escaped URI in toString():
http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/URI.html
I wasn't able to find another proven and open sourced class doing that, so this
patch adds commons-httpclient plus jcl-over-sl4j (since one of the httpclient
classes used uses jakarta commons logging) to the dependencies. I reckon this
could be improved by just embedding the few classes used into the final bundle
to keep the bundle imports stable, but I don't know how to configure that
properly.
The nice thing about httpclient URI is that it accepts both full absolute and
relative URIs, so the if (mappedPathIsUrl) / else block could be removed and
handled as one case. This is required as also relative URIs, ie. with a path
only, need to be escaped at the end, which is now always done by httpclient URI
for us.
The patch also adds a new test testMapURLEscaping() to JcrResourceResolverTest
that tests this issue (only with spaces).
(patch to be applied in bundles/jcr/resource)
was (Author: alexander.klimetschek):
Attaching patch that solves the issue by using the URI class from
commons-httpclient 3.1, which can accept unescaped uri strings, can update the
unescaped path part and properly return an escaped URI in toString().
I wasn't able to find another proven and open sourced class doing that, so this
patch adds commons-httpclient plus jcl-over-sl4j (since one of the httpclient
classes used uses jakarta commons logging) to the dependencies. I reckon this
could be improved by just embedding the few classes used into the final bundle
to keep the bundle imports stable, but I don't know how to configure that
properly.
The nice thing about httpclient URI is that it accepts both full absolute and
relative URIs, so the if (mappedPathIsUrl) / else block could be removed and
handled as one case. This is required as also relative URIs, ie. with a path
only, need to be escaped at the end, which is now always done by httpclient URI
for us.
The patch also adds a new test testMapURLEscaping() to JcrResourceResolverTest
that tests this issue (only with spaces).
(patch to be applied in bundles/jcr/resource)
> JcrResourceResolver.map() does not return proper escaped URIs
> -------------------------------------------------------------
>
> Key: SLING-1218
> URL: https://issues.apache.org/jira/browse/SLING-1218
> Project: Sling
> Issue Type: Bug
> Components: JCR
> Affects Versions: JCR Resource 2.0.6
> Reporter: Alexander Klimetschek
> Attachments: SLING-1218.patch
>
>
> The JcrResourceResolver's map() methods do not escape the URIs that are
> returned (as string). For example, a path with spaces (which is valid in JCR)
> such as
> /content/path/with spaces.jpg
> will be returned as-is (or like "http://my.domain.com/content/path/with
> spaces.jpg" if a mapping config is present for that). However, it should be
> returned as
> /content/path/with%20spaces.jpg
> (Or in case of a mapping config, like
> "http://my.domain.com/content/path/with%20spaces.jpg";).
> Furthermore, in case of a mapping config present, an URISyntaxException
> exception will be thrown in line 384 of JcrResourceResolver as the uri string
> "mappedPath" contains spaces and cannot be parsed by java.net.URI(String),
> which expects an already-escaped URI. That exception is catched internally,
> but namespace mangling and prepending of the servlet context path are omitted
> in that case.
> The use of java.net.URI is not good when it is about building URIs from
> plain, unescaped components, since it only really supports parsing of escaped
> uri strings and the multi-args constructor in conjunction with toString()
> simply behaves wrong. See also http://blog.limewire.org/?p=261
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
![http://my.domain.com/content/path/with%20spaces.jpg"](http://my.domain.com/content/path/with%20spaces.jpg"){kind=link}