You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2008/02/07 09:21:08 UTC

[jira] Created: (SLING-230) ResourceResolver.resolve methods should not consider parent paths

ResourceResolver.resolve methods should not consider parent paths
-----------------------------------------------------------------

                 Key: SLING-230
                 URL: https://issues.apache.org/jira/browse/SLING-230
             Project: Sling
          Issue Type: Bug
          Components: Resource
            Reporter: Felix Meschberger
            Assignee: Felix Meschberger
             Fix For: 2.0.0


Currently the ResourceResolver.resolve methods cut off at the end of the path at dots to find a resource. If the resolve method is called for a non-GET/HEAD request, the parent path is considered after cutting off the last dot. The resolve(String) method acts as if it would be non-GET/HEAD call at the moment.

This is probably wrong in many aspects:

    * If we call DELETE (e..g for WebDAV) on a resource, we should not consider the parent either
    * If we call POST (e.g. for WebDAV), we should not consider the parent
    * resolve(String) should resolve what we have and not go up to the parent

After thinking this through, I come to the conclusion, that considering the parent or not is application specific and cannot be decided upon in the resolve() methods. Therefore I suggest to change this behaviour and not consider the parent path at all.

This has an influence on the UjaxPostServlet, which depends on going to the parent, but this can be easily fixed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (SLING-230) ResourceResolver.resolve methods should not consider parent paths

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

Felix Meschberger closed SLING-230.
-----------------------------------

    Resolution: Fixed

Implemented this change in Rev. 619319.

The ResourceResolver now always only cuts off at dots and "fails" if this leads to no resource. So the only difference between the two resolve() method now is that the resolve(HttpServletRequest) method returns a Non existing resource while the resolve(String) method returns null if no resource can be found.

> ResourceResolver.resolve methods should not consider parent paths
> -----------------------------------------------------------------
>
>                 Key: SLING-230
>                 URL: https://issues.apache.org/jira/browse/SLING-230
>             Project: Sling
>          Issue Type: Bug
>          Components: Resource
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: 2.0.0
>
>
> Currently the ResourceResolver.resolve methods cut off at the end of the path at dots to find a resource. If the resolve method is called for a non-GET/HEAD request, the parent path is considered after cutting off the last dot. The resolve(String) method acts as if it would be non-GET/HEAD call at the moment.
> This is probably wrong in many aspects:
>     * If we call DELETE (e..g for WebDAV) on a resource, we should not consider the parent either
>     * If we call POST (e.g. for WebDAV), we should not consider the parent
>     * resolve(String) should resolve what we have and not go up to the parent
> After thinking this through, I come to the conclusion, that considering the parent or not is application specific and cannot be decided upon in the resolve() methods. Therefore I suggest to change this behaviour and not consider the parent path at all.
> This has an influence on the UjaxPostServlet, which depends on going to the parent, but this can be easily fixed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (SLING-230) ResourceResolver.resolve methods should not consider parent paths

Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SLING-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566493#action_12566493 ] 

Bertrand Delacretaz commented on SLING-230:
-------------------------------------------

I agree that going up the path in Resource resolution only makes sense when creating nodes.

For example, assuming an empty repository, both these URLs should create new nodes:

  /content/somewhere/somenode
  /xyz/*

But that's it, so it makes sense to isolate this behaviour in ujaxPostServlet.

> ResourceResolver.resolve methods should not consider parent paths
> -----------------------------------------------------------------
>
>                 Key: SLING-230
>                 URL: https://issues.apache.org/jira/browse/SLING-230
>             Project: Sling
>          Issue Type: Bug
>          Components: Resource
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: 2.0.0
>
>
> Currently the ResourceResolver.resolve methods cut off at the end of the path at dots to find a resource. If the resolve method is called for a non-GET/HEAD request, the parent path is considered after cutting off the last dot. The resolve(String) method acts as if it would be non-GET/HEAD call at the moment.
> This is probably wrong in many aspects:
>     * If we call DELETE (e..g for WebDAV) on a resource, we should not consider the parent either
>     * If we call POST (e.g. for WebDAV), we should not consider the parent
>     * resolve(String) should resolve what we have and not go up to the parent
> After thinking this through, I come to the conclusion, that considering the parent or not is application specific and cannot be decided upon in the resolve() methods. Therefore I suggest to change this behaviour and not consider the parent path at all.
> This has an influence on the UjaxPostServlet, which depends on going to the parent, but this can be easily fixed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.