RE: Some problems with the WebDAV protocol (part 2: DELETE)

> > > However, RFC 2518 clearly states: "If an error occurs with a
> > > resource other than the resource identified in the
> Request-URI then the
> > > response MUST be a 207 (Multi-Status)." Now clearly, if there
> are any member
> > > resources (let alone all of them) that could not be deleted,
> then an error
> > > occurred with a "resource other than the resource identified in the
> > > Request-URI", and so I should return a 207.
> >
> > Good point.  This requirement is contrary to our intent, which
> was that if
> > all resources were affected by the same error, just a single HTTP status
> > code for that error need be reported.  I'll add an item to the WebDAV
> > Distributed Authoring Protocol issues list for this, since this
> should be
> > cleaned up when we go from Proposed to Draft Standard.
>
> I'd like to point out two further things in this context:
>
> 1) Precisely the same statement ("If an error occurs with a resource other
> than the resource identified in the Request-URI then the response MUST be
> a 207 (Multi-Status).") appears in several places in RFC 2518. In
> particular,
> it appears in the context of both COPY and MOVE. You might want to check
> whether it might be saying the wrong thing in those other places as well.

Another good point.  We will definitely examine these other cases as well.

> 2) Merely saying that "the response MUST be a 207" doesn't really specify
> what the response should be.

In practice, the language in RFC 2518 has been sufficient to allow people to
implement Multi-Status correctly.

> If I am to interpret this as saying that I
> should return a separate status code for each and every member resource,
> then it has a scalability problem: what happens if there where
> 10,000 member resources? If I am to interpret this as saying that I should
> somehow compile a reasonable error report to reflect the problems that
occurred,
> then I don't see how exactly I should do it and how clients would be able
> to properly process this information.

There are response minimization rules defined in RFC 2518 (for example, see
the bottom of section 8.8.3) to address this concern.  Do these rules fall
short in some way?

- Jim

Received on Sunday, 2 May 1999 19:34:41 UTC