Thanks everybody for your suggestions, I have now implemented
SLING-3203 using status code 403 with a descriptive message. And an
integration test.
-Bertrand
Hi
Am 22.01.2014 um 13:12 schrieb Dominik Süß :
> 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
> co
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 differ
On Wed, Jan 22, 2014 at 9:58 AM, Felix Meschberger 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 Sli
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
I agree, so +1 for the patch (with 404)
Carsten
2014/1/21 Bertrand Delacretaz
> 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
>
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 reje