[
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.
