- From: Steinar Bang <sb@metis.no>
- Date: Tue, 10 Jul 2001 09:41:51 +0200
- To: w3c-dist-auth@w3.org
>>>>> "Clemm, Geoff" <gclemm@rational.com>: > From: Steinar Bang [mailto:sb@metis.no] >> but I don't know whether or not servers tend to fail requests to >> get write-locks on read-only resources. >> I thought 8.10.7 of RFC 2518 would require them to return a 412 in >> this case (ie. "lock token not enforcable on this resource")...? > A write lock does not guarantee the lock-token-holder the ability to > write to a resource ... it just denies non-lock-token-holders that > ability. So a server would be enforcing the lock, even if there are > reasons (such as ACLs) that prevent the lock-holder from writing to > the resource. I think allowing locks on non-writable resources will create a lot of confused client writers. What's the rationale for keeping lock functionality separate from the writability of a resource?
Received on Tuesday, 10 July 2001 03:41:57 UTC