- From: Yoram Last <ylast@mindless.com>
- Date: Mon, 19 Apr 1999 00:40:42 +0300
- To: w3c-dist-auth@w3.org
> > 1) WebDAV redefines these methods in a way which is essentially > > incompatible with HTTP/1.1. Thus putting itself in conflict with > > HTTP/1.1. > > Actually, they are compatible with the HTTP/1.1 spec. HTTP/1.1 says: "applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class". So an HTTP/1.1 client must interpret a 207 as being the same as a 200, although it clearly has a totally different meaning in WebDAV. It seems to me that a server which provides an error response (to an HTTP/1.1 request) as a 207 is not acting in an HTTP/1.1 compliant manner. > > 2) WebDAV does not seem to provide a way for servers to differentiate > > WebDAV clients from other HTTP/1.1 clients (at least not in the > > context of clients using these request methods). > > That's a feature. It would be a legitimate feature if WebDAV was only introducing new methods. In such case the request itself, which uses a new method, indicates to the server the use of the new protocol. But if given methods have different semantics in the two protocols, then what kind of a "feature" is that? I call it a bug. > > While a > > server may clearly forbid such PUT operations (it may impose > > whatever restrictions it wants on its name space), a friendly > > PUT implementation (which tries to maximize its functionality) > > should transparently create missing collections (since HTTP/1.1 > > has no MKCOL method or an equivalent). > > That's a matter of opinion; I say it should be possible to delete a collection and > know that clients that don't MKCOL it won't recreate it. The fact is that, as you > admit, the HTTP/1.1 spec does not forbid the behavior which DAV prescribes. Nor does HTTP/1.1 forbids to disallow PUT altogether, or to disallow resource names to have more than 5 characters, or... The point is that it does allow functionality that WebDAV forbids, and this functionality is being used (so it's not a purely theoretical matter). > > So, if I have a server on which people can now create collections > > by using existing HTTP/1.1 compliant clients (namely, with PUT), and I > > will go and make it strictly WebDAV compliant, this important functionality > > will be broken. This is a problem. > > So don't make it DAV compliant on the whole server; leave it alone in trees where > people are using PUT. Why? These "trees where people are using PUT" are their web sites. It is exactly where one wants to add WebDAV support, in order to add more functionality to what PUT and DELETE currently allow. Not in order to break the existing functionality. What I'll do is implement WebDAV without obeying this restriction, because it is very unlikely to cause any problem anyway. But what's the point of having a protocol restriction that does nothing useful and encourages people to be non-compliant? > > The restriction on PUT seems totally artificial anyway. A server that has > > a problem to create missing collections is always allowed to forbid it. > > But what is the point in forbidding all servers from doing that? > > Consistency. With what? Why is it important or beneficial in any way? > > 2) WebDAV can introduce new methods to implement its favorable PUT and DELETE > > Ugh. Adding DAV to a server should automatically include the DAV-like functionality > of base HTTP/1.1; there shouldn't be two ways of doing the same thing. Using DAV-like functionality of base HTTP/1.1 is one thing. Redefining that functionality is another. > > Another (not related) problem with the current protocol is the requirement > > that servers must respect PROPFIND with Depth=infinity queries for collections. > > Access control. And this helps how? By making public content repositories outside the scope of WebDAV? Or maybe anything as large as the Linux kernel source tree is outside its scope? (5000 files should yield MegaBytes of XML.) Or maybe clients can be counted on to always know in advance the size of collections, so they will never issue Depth=infinity requests to large ones? Yoram Last
Received on Sunday, 18 April 1999 17:41:17 UTC