W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

RE: WebDAV and write access discovery

From: Eric Sedlar <eric.sedlar@oracle.com>
Date: Tue, 10 Jul 2001 09:57:59 -0700
To: <w3c-dist-auth@w3.org>
Message-ID: <NDBBKNOGFKEBJOOOIOOLIEMKCBAA.eric.sedlar@oracle.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT