- From: Eric Sedlar <eric.sedlar@oracle.com>
- Date: Tue, 10 Jul 2001 09:57:59 -0700
- To: <w3c-dist-auth@w3.org>
Perhaps a better thing to do would be to add privileges controlling who can LOCK a resource? (This could be aggregated under write on particular implementations) --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Steinar Bang > Sent: Tuesday, July 10, 2001 12:42 AM > To: w3c-dist-auth@w3.org > Subject: Re: WebDAV and write access discovery > > > >>>>> "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 12:55:39 UTC