- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 22 Jun 2001 16:59:30 -0400
- To: Ietf-Dav-Versioning <ietf-dav-versioning@w3.org>
Stefan: These kinds of concrete examples are great! I believe it leads to a different conclusion than you perhaps intended, but this allows the discussion to be grounded in concrete interoperability issues, which I think are far more constructive than the somewhat metaphysical directions which I and others have been guilty of in other postings. Comments below ... From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Real world example: my client has to detect and work with lock-null resources. They have no special resource type in RFC 2518. So I have to look at the properties: - resourcetype: not collection - lockdiscovery: a lock-null resource should have a write lock. - getcontentlength: present, but without a value. Well, actually, you would look for the properties and methods that you are going to use, and see if the resource supports them. According to spec: this should work. However 1) IIS pretends to implement lock-null. It creates empty files which do not vanish when the lock expires. Detection of the resource my client creates (successfully according to response code) fails, since the getcontentlength is 0. But I would like to do MKCOL on it... With the DAV:supported-*-set approach, if you want to do a MKCOL, you would check whether MKCOL was in the DAV:supported-method-set. IIS has the opportunity here to tell you what is going on, by *not* putting MKCOL in the DAV:supported-method-set. Contrast this with the DAV:resourcetype approach (i.e. having the client check for the presence of "DAV:lock-null-resource" in DAV:resourcetype). If IIS set this value, and based on it you tried the MKCOL operation (which should work, according to the protocol), you would be disappointed. If IIS was "honest" and left this out of the DAV:resourcetype, then your client would have to assume this resource has *none* of the methods or properties of a lock null resource. Now I'm not in favor of buggy non-compliant servers, but they are there, and it sure looks like we'd be better of using DAV:supported-method-set to deal with this. 2) moddav supports lock-null with some special quirks: at first, the PROPFIND response is OK, but the resource does not expire when the lock timeout says it should. Instead it hangs around for a while afterwards and the timeout value reported in seconds is bigger than 2^31-1. Oops, can this be a valid lock? And if you looked at the actual properties and methods supported by that resource, you'd have a reasonable chance of interoperating with it, as opposed to trying to rely on the meaningfulness of "DAV:lock-null-resource" in the DAV:resourcetype field. 3) Some servers do not accept certain HTTP requests, others produce invalid (e.g. not well-formed) xml and some throw a whole range of nowhere defined properties in the DAV: namespace at a client. And if you looked at the DAV:supported-method-set, you would know whether or not a server accepted those certain HTTP requests or not. Not much you can do about a server that produces invalid XML ... if it does that, it is unlikely you will be able to put much faith in its correctly returning any property value, including DAV:resourcetype or DAV:supported-*-set. Does my client have to work with those servers? It sure does! And it would work even better if it had DAV:supported-*-set to tell it what was really going with the resources on at that server. Would I be glad for a resource type lock-null? Take a wild guess. Not if you had the option of using DAV:supported-*-set (:-). Cheers, Geoff
Received on Friday, 22 June 2001 16:53:47 UTC