Subject: RE: need clarification about COPY to locked resource response cod e

From: "Clemm, Geoff" <[email-masked]>
Date: Sat, 20 Apr 2002 21:10:22 -0400

From: Stefan Eissing [mailto:[email-masked]]

   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.

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

   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

---

From: Stefan Eissing <[email-masked]>
Date: Sun, 21 Apr 2002 11:36:15 +0200

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

> 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

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 21 Apr 2002 12:03:57 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stefan Eissing
> Sent: Sunday, April 21, 2002 11:36 AM
> To: Clemm, Geoff
> Cc: WebDAV
> Subject: Re: need clarification about COPY to locked resource response
> cod e
>
>
>

Nope :-) Status codes *other* than 403 *or* 409 are replaces.

> I have to elaborate. Instead of a response plain vanilla

That would be 423 LOCKED or 403 FORBIDDEN.

>    <DAV:status>HTTP/1.1 403 LOCKED</DAV:status>

Actually, I'd prefer to change/clarify multistatus error reporting to:

- MUST contain response elements for each source resource that wasn't
moved/copied/deleted as specified (however keeping the current optimization
for 424 on ancestors)

- MAY contain response elements for targets that caused the failure.

So we would get something like:

<multistatus xmlns="DAV:">
   <response>
      <href>source</href>
      <status>HTTP/1.1 403 Conflict</status>

<responsedescription><error><destination-locked/></error></responsedescripti
on>
   </response>
   <response>
      <href>http://host/destination/parent</href>
      <status>HTTP/1.1 423 LOCKED</status>
   </response>
   ...
</multistatus>

The benefit being that a client that "blindly" searches for source URIs will
find something. However, a smarter client can extract the additional piece
of information that's available after all.

It might be woth thinking to also add some kind of linkage between the two
response elements.