Re: need clarification about COPY to locked resource response cod e

Am Sonntag den, 21. April 2002, um 03:10, schrieb Clemm, Geoff:

>    From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>
>    Am Freitag den, 19. April 2002, um 10:12, schrieb Julian Reschke:
>
>> In a future WebDAV protocol that supports enhanced error 
>> reporting a la
>> RFC3253, I'd probably suggest:
>>
>> 409 CONFLICT
>> ....
>> <error xmlns='DAV:'><destination-URI-is-locked/></error>
>
>    I don't like this for the simple reason that clients need hardcoded
>    information about each DAV:error _and_ they need to know how to
>    handle HTTP status codes.
>
> I don't see the problem.  Either the client does not care about
> the reason for the error (in which case it just ignores the
> DAV:error value), or it does care, in which case it needs the
> explanation provided by the DAV:error value.  The advantage of
> having both is that you have a simple error code for simple clients,
> and a more comprehensive error code for more sophisticated clients.

One cannot not disagree with this. However, in Julian's example
error responses like 403 and others are replaced with a general
409 and some DAV:error in the response body.

What you are talking about is keeping a 403 response and _adding_
a response body with a more detailed explanation in DAV:error. That
is perfectly fine with me.

>    So I would prefer to use existing HTTP
>    status codes over new DAV:errors.
>
> You can't pack sufficient information into the few bits provided
> by the HTTP status codes, without having the error codes mean subtly
> different things for different methods (the unfortunate path
> initiated by 2518, but avoided by 3253).

I have to elaborate. Instead of a response plain vanilla
HTTP/1.1 403 LOCKED

or Julian's
HTTP/1.1 409 CONFLICT
<DAV:error><DAV:destination-parent-locked/></DAV:error>

I would prefer
HTTP/1.1 207 MultiStatus
<DAV:multistatus>
   <DAV:response><DAV:href>http://host/destination/parent</DAV:href>
   <DAV:status>HTTP/1.1 403 LOCKED</DAV:status>
   </DAV:response>
   ...
</DAV:multistatus>

The problem with this is that for COPY/MOVE, a server would have
to list all non-copied resources as well in the multistatus. Something
to be avoided when a precondition for a operation failed.

So, the best of both worlds would maybe be:
HTTP/1.1 403 LOCKED
<DAV:error>
   <DAV:href>http://host/destination/parent</DAV:href>
   <DAV:status>HTTP/1.1 403 LOCKED</DAV:status>
</DAV:error>

//Stefan


>    Otherwise you need to define also DAV:destination-is-not-accesible,
>    DAV:destination-parent-is-locked, etc.
>
> You define errors at whatever
> is the appropriate level of detail that is useful for
> interoperable implementations.  If the distinction between
> "destination is not accessible" and "destination parent is locked"
> is sufficiently important to merit separate error codes, then separate
> error codes should be defined.
>
> Cheers,
> Geoff
>

Received on Sunday, 21 April 2002 05:36:29 UTC