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.

2) Merely saying that "the response MUST be a 207" doesn't really specify
what the response should be. 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.
 
> This is almost certainly counter to the design of HTTP, which envisioned the
> URL to resource mapping as a giant hash table.  According to this view,
> DELETE should only affect a single entry in the hash table, and perhaps also
> destroy the persistent state associated with the resource, but there is
> nothing in my reading of DELETE which would permit a server to do more than
> this.  It is only the implementation imperatives of trying to map resources
> into a hierarchical file system which leads to the desire to have a DELETE
> on one URI affect other URIs as well.

The mapping of URIs to objects in an hierarchical file system exists as a
common practice regardless of it being outside the scope of HTTP itself.
Those portions of WebDAV that define the namespace and collection
object are merely documenting an existing common practice. There is
hardly a new invention here. In most cases where DELETE is actually
being used, you have a *user* requesting to DELETE an *object*. The user
should know the nature of the object she is requesting to DELETE. Besides,
as far as I can recall, DELETE was first introduced (along with PUT,
BROWSE, and MKDIR) in a product called NaviServer (by a company called
NaviSoft that was later bought by AOL), and it was deleting directory
trees from its first moment of inception. Today's AOLserver is the direct
descendent of the original NaviServer.

> > I don't
> > even know what you mean by "should not depend on *any* state change
> > occurring on the server" (do you?).
> 
> As a matter of fact, I do know what I mean when I say "state change". 

Yes. But, what do you mean by "should not depend"?
 
> AOLpress is a poor choice here, since it was essentially written to work
> against a single server, AOLserver.

Actually, it is an excellent choice here. It is an HTTP application 
and it depends on HTTP DELETE to work properly on its partner server.
It also illustrates (among other things) that your assumption that HTTP
clients are being designed to work with any HTTP compliant server is simply
false. There are many HTTP client applications out there that are designed
to work with specific servers. While they may rely on the server having
some functionality outside what HTTP defines, they also depend on those
portions that are defined by HTTP to work properly. If you break HTTP
compliance of those servers, then you also break those applications. 

> If these clients refresh their view of the remote site without first asking
> for a listing of the remote site's contents are susceptible to trouble from
> HTTP/1.1 servers as well as from WebDAV servers.  A well-written client
> should query the remote server for a file listing after a DELETE if their
> future actions depend on having an accurate view of the remote server.  The
> WebDAV Explorer client always does a PROPFIND after a DELETE for this
> reason.

I generally agree (particularly in cases where an error response of some
kind is returned). However, not all applications are so "well-written."
Besides, assuming that a 200 response to a request indicates that it
actually did what it's supposed to do doesn't seem all that unreasonable
to me.

> b) Your analogy does not hold because the definition of unlink() does not
> state that a success code will be returned  for anything other than a
> removal of a hard link to the persistent state of the file.  In HTTP, the
> definition of DELETE states that this is possible.  The two definitions are
> different, thus the two situations are not truly analogous.

My analogy holds perfectly well in describing the actual impact on any
application that I ever saw that uses DELETE. Do you know a single
existing application for which it doesn't hold?
 
> > You are so very very wrong. AOLpress might not be a purely HTTP/1.1
> > application, but it uses HTTP/1.1 semantics of DELETE. Now if AOL would
> > want to add WebDAV support to their servers (like to their PrimeHost
> > hosting service) they would clearly be facing a conflict. Exactly the
> > same thing holds for Netscape`s Enterprise server. It provides WebDAV-like
> > functionality through implementing a whole zoo of its own HTTP methods,
> > and is so designed to provide authoring capabilities using it's own Web
> > Publisher client. It so happens that even though it has all those other
> > methods, both file and directory removal on this server depend on the
> > HTTP/1.1 DELETE method. Of course, the fact that there are only about
> > 300,000 of these servers on the net does not indicate much. Or does it?
> 
> You tell me -- how many of these servers are used for authoring?

Enterprise servers are designed to provide a complete environment that
is independent of the operating system on which they run and is
administered in full through an HTTP-based layer. They are designed to
use their own user base (or an LDAP user base) and they provide their own
access control and HTTP-based authoring (or content management) tools.
Their authoring environment is, in fact, quite advanced, and supports
such things as locking and versioning. It is supposed to be one of their
strong selling points. The (HTTP-based) content management tools of these
servers are the most natural way of managing whatever content they have.
I think that it is quite safe to assume that these tools are being used on
most of these servers. 

> Furthermore, since both AOLserver and ES define extensions to HTTP/1.1 for
> remote authoring (in fact, this fact that existing authoring clients needed
> to define extensions to HTTP to create viable authoring tools was a primary
> argument in favor of creating the WebDAV standard), how likely is it that
> tools which work against these servers and depend on their non-standard
> extensions will work at all against a WebDAV server?

Funny, but other than the DELETE conflict there should not be any problem
of adding WebDAV to either an AOLserver or an ES. AOLserver doesn't "share"
with WebDAV anything other than HTTP/1.1 methods, and while ES has four
methods that overlap WebDAV (COPY, MOVE, LOCK and UNLOCK), they all use
mandatory headers that can be used to distinguish WebDAV clients from its
native clients. Existing tools which work against these servers will not
fully work against WebDAV servers (unless one would bother to add special
support for them to a WebDAV server). However, to the extent that worthwhile
WebDAV clients would get created (how about M$ Office 2000?), it would be
desirable to be able to add WebDAV support to these servers without breaking
their current clients. One should particularly note the following:
1) Since ESs provide an advanced authoring environment of the kind that
WebDAV aims to create, a lot of people that actually need such an
environment are likely to already be using them. They should thus be
viewed as a primary target for WebDAV.
2) Since ESs already have the inner layer for an advanced authoring
environment, adding WebDAV support to them should be much easier than
adding it to other servers.
3) While it is not clear if and when Netscape itself would want to add
WebDAV support to these servers, one hardly needs to wait for them.
Such support can be added to existing servers by writing an appropriate
NSAPI module (or even a CGI program). This can be done by any third
party.

> For example, what do these servers report in the case where a DELETE is
> issued against a collection that has two members, one that can be deleted,
> and one that has write permission disabled, and cannot be deleted?  Does the
> server have all or nothing semantics (implying some kind of transaction
> support), so that if it cannot delete all the resources, it deletes none?
> Does the server have best-effort semantics, where it would delete the one
> resource, but not the other two (the collection and the resource which
> cannot be deleted due to access control restrictions)?  What status codes
> does it report in these cases?  This behavior is not specified, and as a
> result an HTTP/1.1 client does not know what will happen when it issues a
> DELETE against one of these servers.

I never studied the behavior of these servers in such great detail. Since
both of them are downloadable from the net, you can try them out for yourself.
I do know that they report an error status code in any event that some error
occurred (namely, in any event that not all of the target collection was
deleted) and that their corresponding clients do not depend on any specific
behavior beyond that. Since HTTP does not provide a method like 207 for
delivering precise information, a client is necessarily left in a state of
uncertainty in the event of any such error, and it would need to further
study the remaining portions of the target in order to determine what
actually took place. (The same thing is true for most file managers,
by the way.)

> In my personal opinion, I think the reason this behavior isn't specified is
> because it was never intended to occur.  DELETE should affect only the
> Request-URI, and if an implementation does more, it is non-conformant.

An interesting view. It seems to have little to do with the real world,
though. Given that most web content either resides on actual file systems
or is emulated to be so, how are you going to delete a directory without
affecting its content? Believe it or not, people did not need to wait for
RFC 2518 in order to create applications that behave in a sensible way.

> > As I tried to explain in a previous posting, it isn't even within the
> > legitimate scope of WebDAV to redefine the semantics of HTTP/1.1 methods,
> > and there is clearly no real technical need for it to do it either.
> 
> Actually, the definition of "container-specific semantics" is explicitly
> stated in our charter (http://www.ics.uci.edu/pub/ietf/webdav/charter.html).
> Our charter was approved by the Internet Engineering Steering Group (IESG),
> granting WebDAV WG the authority to work within the scope of this charter.

Your charter starts with: "This working group will define the HTTP
extensions necessary to enable distributed web authoring tools to be
broadly interoperable" and then describes the primary expected derivable
as: "A protocol specification, which describes new HTTP methods, headers,
request bodies, and response bodies, to implement the distributed authoring
and versioning requirements." I don't read anything there about redefining
existing portions of HTTP, and I certainly don't see anything there that
would legitimize taking away any existing HTTP functionality. "Fixing"
HTTP is clearly outside the scope of this charter.

> > As a side remark, you should note that WebDAV would not have suffered one
> > bit from having two notions of PUT/DELETE within its context (which could
> > be distinguished either by a header or by different method names). The
> > WebDAV methods can be defined as you find fit, while the existing HTTP/1.1
> > methods maintain their flexibility to be used as people find it
> > appropriate for their applications.
> 
> I'm sure that someone would have attacked us for providing *no*
> interoperability for downlevel HTTP/1.1 authoring clients in this case.
> Although, in retrospect, this idea does have some merit.

I'm afraid I can't really follow you here. What is defined in HTTP/1.1
is already there. You don't need to do anything about it. All you need
to do is to avoid being in conflict with it.

> > Now whether you like it or not, you created a situation where your
> > protocol is in conflict with HTTP/1.1. While some aspects of this
> > conflict are of yet unknown and hard to determine magnitude, there
> > are other aspects of it that are clearly significant. The only way
> > to comply with both HTTP/1.1 and WebDAV is to forbid DELETE altogether.
> > There is no way of building a fully functional fully compliant WebDAV
> > server that is also fully compliant with HTTP/1.1, and since HTTP/1.1
> > compliance is required by WebDAV itself, it is even a self-conflict.
> > The DELETE method, within its HTTP/1.1 semantics, is currently used
> > on hundreds of thousands of HTTP authoring servers, and your protocol
> > specifies a behavior that breaks the proper functionality of virtually
> > any existing client that uses this method. If that isn't an
> > interoperability problem of your protocol, then I don't know what is.
> 
> We clearly differ on the significance of this interoperability issue.

I believe that if you would really go and study this interoperability
issue, we wouldn't differ at all on its significance.


Yoram

Received on Sunday, 2 May 1999 18:55:08 UTC