You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Stefan Lützkendorf <lu...@apache.org> on 2005/01/17 15:50:16 UTC
What's the correct response for a not supported report?
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 -- luetzkendorf@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: What's the correct response for a not supported report?
Posted by Lisa Dusseault <li...@osafoundation.org>.
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 -- luetzkendorf@apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
> --
> Stefan Lützkendorf -- luetzkendorf@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: What's the correct response for a not supported report?
Posted by Stefan Lützkendorf <lu...@apache.org>.
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 -- luetzkendorf@apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
--
Stefan Lützkendorf -- luetzkendorf@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: What's the correct response for a not supported report?
Posted by Lisa Dusseault <li...@osafoundation.org>.
"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 -- luetzkendorf@apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org