[ https://issues.apache.org/jira/browse/SLING-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-422: ------------------------------------ Description: The SlingPostServlet is anything but REST-ful. For example, it is possible to have a request for resource /a which at the same might cause a resoure /x/y to be moved to /e/f and much nastier things. Providing an accurate response to such operations and acting upon such responses is almost impossible if not introducing multi-status ... Therefore, the SlingPostServlet should be simplified as follows: * The servlet is modified to execute a single operation per request, where an operation may be create/modify, delete, move and copy. The actual operation to execute is indicated by a new parameter ":operation" which can take the following values: <unset> or empty string - create/modify request "delete" - delete current resource "move" - move current resource "copy" - copy current resource In addition, this mechanism could be implemented such, that the actual operation might be extensible. * All operations act on the current resource - request.getResource(). The delete, move and copy operations fail if the current resource is a non-existing resource. * The distinction between create and just modify depends on the resource: If the current resource does not exist yet it is created. Special treatment for resource creation happens if the path is terminated by a slash (as proposed by Carsten and Roy in earlier messages) or by a slash-star (/*, like currently). The name of the newly created node is defined as it is today: using special parameters :name, :nameHint and well-known content such as title. We keep the /* notation to support requests like /*.print.a4.html. * Some operations (create, move, copy) handle a parameter ":order", which defines the ordering relation of the newly created item (this is the same behaviour as in the current implementation) * The copy and move operation by default fail if an item already exists at the destination. This behaviour may be overwritten by setting the ":replace" paramter to "true". This replaces the current "replace" value for the :copyFlags and :moveFlags parameter. * The copy and move operations require another parameter ":dest", which is the destination path name of the resource. The operation fails if the parameter is missing. * The ":redirect" parameter causes the client to be redirected to the desired target in case the operation was successfull. This is the same behaviour as today. * The ":status" parameter causes the HTTP status code to be non-standards-compliant: If the parameter value is "browser", that status code is always 200/OK, even in case of failure. Otherwise the status code will reflect the actual status. * Regardless of the ":status" parameter value, the response is always the complete run-down of the operation executed with the actual status code and eventual exceptions - unless of course if the client has been redirected after successfull operation and instructed to so by the :redirect parameter. This is the same behaviour as today. * Run-Down of some status codes expected: 200/OK - if :status==browser or if the operation succeeded 201/CREATED - required by a successful move or copy, when the destination did not exist yet. Also sent when the current resource was created 404/NOT FOUND - if the current resource is missing for copy, move, delete 412/PRECONDITION FAILED - if the destination for the copy or move operation exists and the :replace parameter is not set to true (this is consistent with the WebDAV spec for COPY/MOVE in this situation). 302/FOUND - aka temporary redirect, if the operation succeeded and the :redirect parameter is set 500/INTERNAL SERVER ERROR - in case of any processing error, e.g. an exception being thrown was: As discussed in [1]: The SlingPostServlet should be default return the correct HTTP status code and response header(s) instead of 200. The XHTML response should still be sent. So we come to three cases: (1) Default: Status code as per the standard with XHTML response containing further details (2) "Browser-Friendly": Status code 200 with XHTML response containing actual status code and further details (3) Redirect: redirect to another location Note, that (1) and (2) are almost identical, except for the HTTP status code being set. (3) takes place if the :redirect request parameter is set and the processing is successful. In particular a redirect will not be sent in case an error occurrs while processing the request even though the :redirect parameter may be set. (1) or (2) take place in case of a processing error or if the :redirect parameter is not set. The distinction between (1) and (2) happens according to the :status parameter. If the parameter is set to "browser" (2) takes place. Otherwise (1) takes place. [1] http://markmail.org/message/uf6nwauggkxwrauc Priority: Critical (was: Major) As discussed in [1], I modify this issue to cause the SlingPostServlet to be refactored and simplified as indicated with the new description. [1] http://markmail.org/message/mu6worv2jxsmmv76 > SlingPostServlet: Return standards complying status code and headers by > default > ------------------------------------------------------------------------------- > > Key: SLING-422 > URL: https://issues.apache.org/jira/browse/SLING-422 > Project: Sling > Issue Type: Improvement > Components: Post Servlets > Reporter: Felix Meschberger > Assignee: Felix Meschberger > Priority: Critical > Fix For: 2.0.0 > > > The SlingPostServlet is anything but REST-ful. For example, it is possible to > have a request for resource /a which at the same might cause a resoure /x/y > to be moved to /e/f and much nastier things. Providing an accurate response > to such operations and acting upon such responses is almost impossible if not > introducing multi-status ... > Therefore, the SlingPostServlet should be simplified as follows: > * The servlet is modified to execute a single operation per request, where an > operation may be create/modify, delete, move and copy. The actual operation > to execute is indicated by a new parameter ":operation" which can take the > following values: > <unset> or empty string - create/modify request > "delete" - delete current resource > "move" - move current resource > "copy" - copy current resource > In addition, this mechanism could be implemented such, that the actual > operation might be extensible. > * All operations act on the current resource - request.getResource(). The > delete, move and copy operations fail if the current resource is a > non-existing resource. > * The distinction between create and just modify depends on the resource: If > the current resource does not exist yet it is created. Special treatment for > resource creation happens if the path is > terminated by a slash (as proposed by Carsten and Roy in earlier messages) or > by a slash-star (/*, like currently). The name of the newly created node is > defined as it is today: using special parameters :name, :nameHint and > well-known content such as title. > We keep the /* notation to support requests like /*.print.a4.html. > * Some operations (create, move, copy) handle a parameter ":order", which > defines the ordering relation of the newly created item (this is the same > behaviour as in the current implementation) > * The copy and move operation by default fail if an item already exists at > the destination. This behaviour may be overwritten by setting the ":replace" > paramter to "true". This replaces the current "replace" value for the > :copyFlags and :moveFlags parameter. > * The copy and move operations require another parameter ":dest", which is > the destination path name of the resource. The operation fails if the > parameter is missing. > * The ":redirect" parameter causes the client to be redirected to the desired > target in case the operation was successfull. This is the same behaviour as > today. > * The ":status" parameter causes the HTTP status code to be > non-standards-compliant: If the parameter value is "browser", that status > code is always 200/OK, even in case of failure. Otherwise the status code > will reflect the actual status. > * Regardless of the ":status" parameter value, the response is always the > complete run-down of the operation executed with the actual status code and > eventual exceptions - unless of course if the client has been redirected > after successfull operation and instructed to so by the :redirect parameter. > This is the same behaviour as today. > * Run-Down of some status codes expected: > 200/OK - if :status==browser or if the operation succeeded > 201/CREATED - required by a successful move or copy, when the destination > did not exist yet. Also sent when the current resource was > created > 404/NOT FOUND - if the current resource is missing for copy, move, delete > 412/PRECONDITION FAILED - if the destination for the copy or move > operation exists and the :replace parameter is not set to true > (this is consistent with the WebDAV spec for COPY/MOVE in this > situation). > 302/FOUND - aka temporary redirect, if the operation succeeded and the > :redirect parameter is set > 500/INTERNAL SERVER ERROR - in case of any processing error, > e.g. an exception being thrown -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.