You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Alexander Klimetschek (JIRA)" <ji...@apache.org> on 2009/12/02 17:54:20 UTC

[jira] Created: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

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


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

    http://localhost:4502/content/dam/geometrixx/portraits/chris%20stark.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.


[jira] Issue Comment Edited: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
    [ 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.


[jira] Commented: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SLING-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793016#action_12793016 ] 

Felix Meschberger commented on SLING-1218:
------------------------------------------

Fixed the problem in Rev. 892640 by copying the source for the URI class from Http Client 3.1 to the JCR Resource Resolver bundle and added missing methods to not require any dependencies to the Http Client 3.1 and Commons Code libraries.

> 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
>            Assignee: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.


[jira] Reopened: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger reopened SLING-1218:
--------------------------------------


Have to reopen this issue, because it breaks the integration build by introducing a dependency to commons codec which is not available in Sling.

> 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
>            Assignee: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.


[jira] Assigned: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger reassigned SLING-1218:
----------------------------------------

    Assignee: Felix Meschberger

> 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
>            Assignee: Felix Meschberger
>         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.


[jira] Resolved: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger resolved SLING-1218.
--------------------------------------

       Resolution: Fixed
    Fix Version/s: JCR Resource 2.0.8

Thanks for providing the patch. I have applied it in Rev. 892252 with a slight modification: Instead of importing the httpclient package, I have included the required classes directly into the JCR Resource Resolver build.

> 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
>            Assignee: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.


[jira] Resolved: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger resolved SLING-1218.
--------------------------------------

    Resolution: Fixed

Now with a last small fix preventing an NPE when trying to map the root path "/" in Rev. 892661 this can be solved.

> 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
>            Assignee: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.


[jira] Updated: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Klimetschek updated SLING-1218:
-----------------------------------------

    Description: 
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

  was:
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

    http://localhost:4502/content/dam/geometrixx/portraits/chris%20stark.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


> 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
>
> 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.


[jira] Issue Comment Edited: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
    [ 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:06 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().

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).
  
> 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.


[jira] Commented: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SLING-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792507#action_12792507 ] 

Felix Meschberger commented on SLING-1218:
------------------------------------------

Committed a temporary solution to the problem in Rev. 892270: just include the httpclient and commons-codec bundles in the build.

Have to find a better solution, though.

> 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
>            Assignee: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.


[jira] Commented: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SLING-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792488#action_12792488 ] 

Felix Meschberger commented on SLING-1218:
------------------------------------------

In Rev. 892262 also enhanced the Web Console plugin to make use of the HttpClient URI class to support seamless encoding.

> 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
>            Assignee: Felix Meschberger
>             Fix For: JCR Resource 2.0.8
>
>         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.


[jira] Updated: (SLING-1218) JcrResourceResolver.map() does not return proper escaped URIs

Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Klimetschek updated SLING-1218:
-----------------------------------------

    Attachment: SLING-1218.patch

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).

> 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.