[ 
https://issues.apache.org/jira/browse/SLING-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803290#comment-13803290
 ] 

Alexander Klimetschek commented on SLING-3203:
----------------------------------------------

Looks good to me. A request to /tmp/test.other/nothing doesn't really make 
sense in the first place if the (full) path does not exist.

Does the same issue apply to these cases?
- a DELETE request (don't know if that shares use of the DeleteOperation)
- a request using a @Delete addressing the local node (not sure if that works):
{code}
POST /tmp/test.other/nothing
with param: ".@Delete" = "true"
{code}
- (are these all ways to delete something?)

Also could the same issue be present for other operations such as move, copy 
etc.?


> Post servlet's delete operation deletes parent of nonexisting node
> ------------------------------------------------------------------
>
>                 Key: SLING-3203
>                 URL: https://issues.apache.org/jira/browse/SLING-3203
>             Project: Sling
>          Issue Type: Bug
>          Components: Servlets
>    Affects Versions: Servlets Post 2.3.2
>            Reporter: Bertrand Delacretaz
>         Attachments: SLING-3203.patch
>
>
> In the below scenario, /tmp/test is gone after the delete operation - the 
> resource resolver goes up the path of the nonexisting node, and it's 
> /tmp/test that's provided to the DeleteOperation.
> I think we should change this (maybe with a backwards compatibility switch), 
> as it's clear that the user's intention in this case is not to delete 
> /tmp/test. Maybe just reject :delete operations if the request has any 
> selector or extensions.
> curl -u admin:admin -X POST http://localhost:8080/tmp/test/some.node
> curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # looks good
> curl -u admin:admin -F:operation=delete 
> http://localhost:8080/tmp/test.other/nothing
> curl -u admin:admin http://localhost:8080/tmp/test.tidy.2.json # 404



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to