Re: WebDAV and write access discovery

>>>>> "Clemm, Geoff" <gclemm@rational.com>:

> You are not allowed to send a Expect request header if you do not
> intend to send a request body (Section 8.2.3):

>         A client MUST NOT send an Expect request-header field (section
>         14.20) with the "100-continue" expectation if it does not intend
>         to send a request body.

Yes, I missed that.  Thanx for the clarification.

> An early terminated PUT request (i.e. without a message body) should
> be treated by the server as a failure by the client, and not as a
> 0-length content update.  But the overhead of having the client
> prematurely terminate a connection (to get the PUT to fail) or wait
> for the server to timeout the connection, would make it unadvisable
> to use this as a techique for finding out whether the resource is
> readonly.

I agree.

> When the ACL protocol is implemented, that would be the best way to
> determine whether a resource is readonly.  If it is a Class 2 DAV
> server, trying to get a write lock might be something to try,

That was my next idea, also.

After I have done a GET, immediately start a LOCK on the same
resource, and then either UNLOCK the lock (to try to grab it again, if
I ever wish to attempt a PUT), or let it time out (and refresh it
before a PUT).

Yet another approach would be to do a PROPFIND on the resource, to see
if it has any locks.  Or aren't lock tokens listed as properties?
(One tricky bit here would be to map from the HREF to the authenticated
user, but presumably I would know what URL I set myself.)

I wonder what eg. Word 2000 does?  Does it mark everything as R/W, and
just PUT, and then report a failure?

> 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")...?
	<http://andrew2.andrew.cmu.edu/rfc/rfc2518.html#sec-8.10.7>

Received on Thursday, 5 July 2001 02:31:12 UTC