Re: Some problems with the WebDAV protocol

> > Why do you think that you must *require* things to be one way or
> > the other?
> 
> In general, when we stated a requirement in the specification, we made it a
> MUST, and then needed to be argued down from that level, rather than
> starting at a MAY or SHOULD, and arguing up to a MUST.  

This seems to explain why the protocol has so many MUSTs, including some
that should really be SHOULDs. I don't think this design approach is
necessarily better or worth than any other, but at the end of the day,
MUSTs that should be SHOULDs are bugs, and SHOULDs that should be MUSTs
are bugs. Both of these things create interoperability problems, and
make life more complicated.

> 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
safe and inevitable to assume that an application would behave in a
compliant manner with respect to functionality that can't possibly be
obtained otherwise, but it would be very dangerous to assume compliance
with a non-essential protocol requirement just because it is a "MUST".
Applications must (in the real sense of must) be compliant with those
things that are truly essential because otherwise no partner program
will be sufficiently tolerant to work with them. But if they fail to
comply with something that is not really essential, then most partners
would be sufficiently tolerant to deal with that. So you have this
positive feedback dynamics that eventually filters out those things that
are real MUSTs from those that are not. Therefore, the ideal thing is if
the set of MUSTs in the protocol matches exactly those things that are
truly essential, because this is the only way to achieve real-world
compliance and to make it possible to write a working application by
just looking at the requirements of the protocol. Otherwise things become
more chaotic and writing interoperable applications becomes harder.

> > Surely, ftp is more
> > popular, but given the large number of PUT-enabled applications and the
> > convenience of using the same namespace for both viewing and uploading, I
> > tend to believe *some* people are using it. If a large hosting operation
> > has even a small percentage of its users relying on that functionality,
> > they may run into a serious headache if they suddenly disable it. I think
> > that breaking existing applications (and even more so breaking people's
> > work habits) is something that should be avoided unless it is truly
> > necessary or proven to be a non-issue (not the other way around).
> 
> Well I think that most people are completely unaware of this (for the user
> population) undocumented feature, and don't use 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
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
names can be fully addressed within this framework, because the client can
(if it wants to) check for the existence of target collections (using HEAD),
and impose on the user to create collections one by one, etc. I'm not
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.

It is also not completely clear to me that WebDAV obsoletes the limited
write capabilities of HTTP/1.1, which exists as an independent protocol.
In principle, at least, people can keep writing and using pure HTTP/1.1
clients and servers for many years to come, and so having this kind of
conflict between the two protocols is not healthy.

I believe that you are absolutely right that "most people are
completely unaware of this", but this does not contradict having
*some* people that rely on it, which suffices to create a problem.

In any event, from a practical point of view, I can think of three questions
here:

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.

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

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.

What do you think?

> > I agree that this whole thing is not such a "big" issue, but not for the
> > same reason as you. The thing that makes it pretty benign is that nothing
> > at all will happen to WebDAV interoperability if this requirement would
> > be ignored.
> 
> My concern here is if a DAV client is written which depends on the
> intermediate collections *not* being made (i.e., it depends on an error
> being thrown if a user mis-types an intermediate collection name), then this
> client would haev interoperability problems against a server which did
> implement the intermediate collections.

OK; you got me convinced on this one. A poorly designed WebDAV client may
indeed have problems, and in this respect, this is a bigger issue than I
thought.


Yoram

Received on Wednesday, 21 April 1999 01:04:02 UTC