- From: Ilya Kirnos <ilya.kirnos@oracle.com>
- Date: Mon, 30 Jul 2001 18:58:45 -0700
- To: w3c-dist-auth@w3.org
> This would be fine with me as well. It basically says that if a LOCK > is applied to an unmapped URI, the LOCK is automatically preceded with > a PUT with a zero-length body. As Stefan and Lisa say, having a > zero length resource remain when the LOCK is removed will not cause > a problem with existing clients, and clients that care about IIS already > cannot expect to be able to apply MKCOL to a "lock null" resource. > If we didn't already have clients that expected a LOCK on an unmapped > URI to succeed, I'd prefer to just say that the LOCK just returns 404 > on an unmapped URI, but I can live with this compromise proposal. I agree: my first choice would be for abandoning the concept of a null lock, but if people feel strongly they should be kept, the semantics should be changed to allow the server to create an actual file to track the lock. Among other things, this allows other protocols to have at least a shot at playing nice with DAV locks. This point (interoperability with other protocols) has been brought up a couple of times in this discussion already, and is an important consideration for the server I'm working on (Oracle iFS), and I suspect for others as well. It can't just be ignored. -ilya
Received on Monday, 30 July 2001 21:57:54 UTC