You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2014/01/21 14:44:14 UTC
SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
Hi,
What do people think about applying the SLING-3203 patch?
It causes the POST servlet to reject any :delete operation that has a
selector, extension or suffix - might cause some backward incompatible
behavior but the current behavior feels wrong to me.
The patch returns a status 400 when rejecting the request, we'd change
that to 404 as discussed there.
WDYT?
-Bertrand
Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
Posted by Carsten Ziegeler <cz...@apache.org>.
I agree, so +1 for the patch (with 404)
Carsten
2014/1/21 Bertrand Delacretaz <bd...@apache.org>
> Hi,
>
> What do people think about applying the SLING-3203 patch?
>
> It causes the POST servlet to reject any :delete operation that has a
> selector, extension or suffix - might cause some backward incompatible
> behavior but the current behavior feels wrong to me.
>
> The patch returns a status 400 when rejecting the request, we'd change
> that to 404 as discussed there.
>
> WDYT?
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Thanks everybody for your suggestions, I have now implemented
SLING-3203 using status code 403 with a descriptive message. And an
integration test.
-Bertrand
Re: SLING-3203 - rejecting POST/delete if any selector, extension
or suffix?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 22.01.2014 um 13:12 schrieb Dominik Süß <do...@gmail.com>:
> I just checked the RFC for statuscodes and 403 seems appropriate while 409
> seems to be wrong.
> Although you could argue the user can resolve the conflict by changing the
> URI the new URI has a new target (since the URI does not know about
> concepts like selectors or suffixes) and therefore is a different request
> (the versioning example indicates that the intention is a conflict created
> by the payload).
Yes, that was my idea for 409. But I am fine with 403, too.
Regards
Felix
> IMHO 403 would be good and could return an info what
> exactly was wrong with the request (like "Found suffix [extension |
> selectors] for POST request").
>
> Regards,
> Dominik
>
>
> On Wed, Jan 22, 2014 at 10:34 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>
>> On Wed, Jan 22, 2014 at 9:58 AM, Felix Meschberger <fm...@adobe.com>
>> wrote:
>>> ...I am not sure about the 404 response. How about 409/CONFLICT or
>> 403/FORBIDDEN ?
>>
>> 403/FORBIDDEN sounds good, will do that.
>>
>>>
>>> Finally: Lets consider not allowing selector, extension, and suffix on
>> all requests handled by the SlingPostServlet ?
>>
>> That's a different topic.
>> -Bertrand
>>
Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
Posted by Dominik Süß <do...@gmail.com>.
I just checked the RFC for statuscodes and 403 seems appropriate while 409
seems to be wrong.
Although you could argue the user can resolve the conflict by changing the
URI the new URI has a new target (since the URI does not know about
concepts like selectors or suffixes) and therefore is a different request
(the versioning example indicates that the intention is a conflict created
by the payload). IMHO 403 would be good and could return an info what
exactly was wrong with the request (like "Found suffix [extension |
selectors] for POST request").
Regards,
Dominik
On Wed, Jan 22, 2014 at 10:34 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
> On Wed, Jan 22, 2014 at 9:58 AM, Felix Meschberger <fm...@adobe.com>
> wrote:
> > ...I am not sure about the 404 response. How about 409/CONFLICT or
> 403/FORBIDDEN ?
>
> 403/FORBIDDEN sounds good, will do that.
>
> >
> > Finally: Lets consider not allowing selector, extension, and suffix on
> all requests handled by the SlingPostServlet ?
>
> That's a different topic.
> -Bertrand
>
Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jan 22, 2014 at 9:58 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...I am not sure about the 404 response. How about 409/CONFLICT or 403/FORBIDDEN ?
403/FORBIDDEN sounds good, will do that.
>
> Finally: Lets consider not allowing selector, extension, and suffix on all requests handled by the SlingPostServlet ?
That's a different topic.
-Bertrand
Re: SLING-3203 - rejecting POST/delete if any selector, extension
or suffix?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
As noted in the issue: I agree that we should do this.
I am not sure about the 404 response. How about 409/CONFLICT or 403/FORBIDDEN ?
Finally: Lets consider not allowing selector, extension, and suffix on all requests handled by the SlingPostServlet ?
Regards
Felix
Am 21.01.2014 um 14:44 schrieb Bertrand Delacretaz <bd...@apache.org>:
> Hi,
>
> What do people think about applying the SLING-3203 patch?
>
> It causes the POST servlet to reject any :delete operation that has a
> selector, extension or suffix - might cause some backward incompatible
> behavior but the current behavior feels wrong to me.
>
> The patch returns a status 400 when rejecting the request, we'd change
> that to 404 as discussed there.
>
> WDYT?
> -Bertrand