Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
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 bdelacre...@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
Re: SLING-3203 - rejecting POST/delete if any selector, extension or suffix?
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 bdelacre...@apache.org wrote: On Wed, Jan 22, 2014 at 9:58 AM, Felix Meschberger fmesc...@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?
Hi Am 22.01.2014 um 13:12 schrieb Dominik Süß dominik.su...@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 bdelacre...@apache.org wrote: On Wed, Jan 22, 2014 at 9:58 AM, Felix Meschberger fmesc...@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?
Thanks everybody for your suggestions, I have now implemented SLING-3203 using status code 403 with a descriptive message. And an integration test. -Bertrand
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
