Yes, it looks like 409 is justifiable in that case!
Lisa
On Jan 19, 2005, at 3:15 AM, Stefan L�tzkendorf wrote:
Thanks,
so we should return
HTTP/1.1 403 Forbidden
Date: Mon, 17 Jan 2005 14:03:15 GMT
<D:error xmlns:D="DAV:"><D:supported-report/></D:error>
If the requested report was a version-tree report, and the requested
resource supports VERSION-CONTROL, should we then return 409, because
later the reuest may be successfull?
Stefan
Lisa Dusseault wrote:
"Precondition failed" is a very attractive response code to use in
many situations because as English it's so vague, but in HTTP the
meaning of Precondition is very clear: it's a header from a limited
set of headers that put conditions on the success of the response.
HTTP 2616 defined If-Modified-Since, If-Not-Modified, If-Match and
If-Not-Match. HTTP 2518 added the If header to that list.
I think interoperability is slightly better if we continue to limit
use of 412 Precondition Failed to cases where the client put a
Precondition header on the request and that's the reason why it
failed.
RFC3253 uses the word "precondition" in a slightly different although
clearly related sense -- these are the preconditions that the *spec*
has for success of the request, rather than preconditions defined by
the *client* in its request. For specification preconditions,
RFC3253 recommends using 403 or 409 as the response code. This para
from 3253:
A "precondition" of a method describes the state of the server that
must be true for that method to be performed. A "postcondition" of a
method describes the state of the server that must be true after
that method has been completed. If a method precondition or
postcondition for a request is not satisfied, the response status of
the request MUST be either 403 (Forbidden) if the request should not
be repeated because it will always fail, or 409 (Conflict) if it is
expected that the user might be able to resolve the conflict and
resubmit the request.
And there is a specification precondition defined for this precise
case:
Preconditions:
(DAV:supported-report): The specified report MUST be supported
by the resource identified by the request-URL.
So putting these together, the spec recommends a response of 403 with
a body containing <DAV:supported-report/> in the error element.
Lisa
On Jan 17, 2005, at 6:50 AM, Stefan L�tzkendorf wrote:
Hello Folks,
I have a question regarding WebDAV specifications.
Question: what is the correct response to an request of an
unsupported report?
E.g. how should we answer to a "version-tree report" request on a
resource that is not version controlled?
Currently slide returns some thing like this:
HTTP/1.1 207 Multi-Status
Transfer-Encoding: chunked
Date: Mon, 17 Jan 2005 14:03:15 GMT
Server: Apache-Coyote/1.1
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/webdav/BCS/Projekte/Dok2.doc</D:href>
<D:propstat>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription>
<D:error>
<D:supported-report />
</D:error>
</D:responsedescription>
</D:propstat>
</D:response>
</D:multistatus>
This looks weird, because we return a <propstat> element that does
not contains any <prop> element.
I think a 412 (Precondition Failed) response is more appropriate,
because supported-report is a statet precondition of REPORT in
RFC3253.
So i'd like to response as the following:
HTTP/1.1 412 Precondition Failed
Transfer-Encoding: chunked
Date: Mon, 17 Jan 2005 14:03:15 GMT
Server: Apache-Coyote/1.1
<D:error>
<D:supported-report />
</D:error>
Any thoughts? What is the most conformant form?
Thanks in advance,
Stefan
--
Stefan L�tzkendorf -- [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Stefan L�tzkendorf -- [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
