Re: Some problems with the WebDAV protocol

As another server vendor, I vigorously support all of Greg's points.

Like Greg and Jim, although very interested in any errors or lack
of clarity in the current WebDAV RFC, I have little sympathy for
attempts to change the semantics for anything short of a major
interoperability problem.  The time for fiddling around the edges has
passed.  Major vendors are coding against this specification.  It is
*far* more important that it be stable, than that it be "improved".

There are at least three WebDAV extension working groups (Advanced
Collections, Versioning, DASL).  If you think that your
extension/modification is important, you are free to propose it to one
of those working groups, or start your own working group.  But you
will be held to the standard of maintaining interoperability with the
existing WebDAV protocol.

Cheers,
Geoff

   From: Greg Stein <gstein@lyra.org>

   On Wed, 21 Apr 1999, Yoram Last wrote:
   > > A client can depend
   > > on a MUST requirement, but it cannot depend on SHOULD or MAY requirements.
   > > Furthermore, SHOULD and MAY requirements often lead to feature discovery,
   > > which complicates a protocol.  MUST requirements generally increase
   > > interoperability, since they are features which can be expected to be
   > > present.
   > 
   > In theory. More precisely, in the theory which is built on the axiom
   > that applications get implemented in a fully compliant manner. But, this
   > is almost never the case. Now in practice, a client (or server) designed
   > for maximum interoperability should make the minimal possible set of
   > assumptions about "good behavior" of the other side. It is usually both

   As a server implementor, I am going to code to the spec. If you have a
   broken client, then TFB. From my point of view, the theory that servers
   build to spec is absolutely valid. Several times people have pointed out
   conformance issues with mod_dav. That is definitely a bug, so I fix them.

   There is absolutely no way that I am going to help to propagate bad client
   programming practices. If a client doesn't interoperate with mod_dav and
   it is the client's fault, then I won't raise a finger.

   Your argument above seems to presume that implementors should compensate
   for buggy clients. That is simply Bad and Wrong. There is no justification
   for it.

   > I don't agree that this is an "undocumented feature" or a "side-effect".
   > It is a functional feature that includes the functionality of WebDAV PUT
   > along with MKCOL in one command. One could argue, in fact, that MKCOL is
   > not necessary, because one can implement it by PUTing a null (zero size)
   > file and then DELETEing it. (Some applications actually tend to do that

   The definition of PUT does **NOT** state that intermediates must be
   created. Therefore, I won't do it.

   What will you do now? Your clients better be able to deal with that fact.
   Any number of other servers will respond similarly, and those clients
   should be able to deal.

   [please excuse the belligerance here, but I feel that you're not
   sufficiently backing up your claims... Jim has asked for real-world
   examples of problems and you have not yet provided them. From my point of
   view, you have not shown that anything must "be fixed".]

   > implicitly, because they do a "write test" of this type before uploading
   > a file to a new location.) Issues like mis-types of intermediate collection

   This is just bogus. DAV at least defines a specific behavior for
   conformance. That absolutely helps the situation. Clients don't need to
   "test" what will happen. They will simply know.

   > saying it is the best way of doing things, but it is there. Now since
   > the simpler way of implementing PUT (on the server side) is to not have
   > it create collections, the fact that some server implementors made the
   > effort to enable it says that *they*, at least, considered it a feature
   > that is worthwhile implementing.

   Goody for them. That does not dispell the fact that clients that have not
   handled the situation for servers that have **NOT** implemented PUT this
   way. As long as those clients do not compensate, then they are broken.
   This is all quite valid per the HTTP/1.1 specification.

   > 1) Is it a bug that should have been avoided had it been thought of before?
   > 
   > 2) Is it so huge a problem that it justifies by itself re-issuing the protocol
   > (or should play a major role in a decision to do so)?
   > 
   > 3) Is it something that should be fixed in later revisions of the protocol?
   > 
   > My answers are:
   > 
   > 1) Yes it's a bug. A conflict of this type with HTTP/1.1 should not have been
   > introduced into the protocol.

   This is your subjective opinion. I do not believe this behavior is a bug.
   The HTTP/1.1 specification supports my server behavior (that of refusing
   to create intermediate collections).

   > 2) Most probably not. I believe that the actual interoperability problem here
   > is overall quite mild. 

   As long as the actual *fact* is that the problem is mild, then this whole
   issue is totally moot. As Jim has asked, please demonstrate where this
   "issue" causes problems. What clients are *dependent* on the
   create-intermediate-collection behavior?

   The basic fact here is that RFC 2518 specifies a behavior that you do not
   agree with. From what I have seen, the consensus opinion seems to disagree
   with you. IETF is consensus based, and the issuance of an RFC creates a
   yet another bar for you to overcome. I certainly don't want to discourage
   you, but I *do* desire to make it clear that some objective facts will go
   a long way to help your case.

   > 3) Probably. It really depends on what happens between now and then. I think
   > that the probability of the current prohibition becoming really important
   > to any application is small, and so unless things turn out differently,
   > it should be fixed in the future.

   This is presumptive on the belief that a problem exists. I maintain none
   exists, so this point is moot.

   Cheers,
   -g

   --
   Greg Stein, http://www.lyra.org/

Received on Wednesday, 21 April 1999 08:17:48 UTC