[
https://issues.apache.org/jira/browse/SLING-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-1899:
----------------------------------
Attachment: 101216_mapresolv_specialchars_fix.patch
attached is a fix, that resolves the problem:
[^101216_mapresolv_specialchars_fix.patch]
if applied, the unit "testMapURLEscaping" fails. but in my opinition, this unit
test is not correct either and should be removed/adapted to a non-escaped URI.
> JcrResolver map method is not reverse operation of resolve method with
> special chars in path
> --------------------------------------------------------------------------------------------
>
> Key: SLING-1899
> URL: https://issues.apache.org/jira/browse/SLING-1899
> Project: Sling
> Issue Type: Bug
> Components: JCR
> Affects Versions: JCR Resource 2.0.6
> Reporter: Stefan Seifert
> Attachments: 101216_mapresolv_specialchars_fix.patch,
> 101216_mapresolve_specialchars_test.patch
>
>
> accoring to the javadocs of the ResourceResolver API interface, the map
> method is inteded as the reverse operation of the resolve method.
> this is not the case if the path contains special chars like spaces - they
> are url-encoded, although the javadocs of the API does not require this.
> additionally the resolve method does not url-deocde the path (which is
> correct in my opinion because the servlet engine already decodes the path).
> the map method should be fixed, so that not url-encoding takes place in it.
> the application is responsible for url-encoding a path if needed, not the
> sling api.
> i've attached a patch which contains a simple unit tests that makes the
> current implementation fail when resolving a path generated with the map
> method: [^101216_mapresolve_specialchars_test.patch]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
