Re: Some problems with the WebDAV protocol

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 03:08:27 UTC