Subject: RE: WebDAV and write access discovery

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 2 Jul 2001 11:08:28 -0400

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.

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.

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,
but I don't know whether or not servers tend to fail requests
to get write-locks on read-only resources.

Cheers,
Geoff

-----Original Message-----
From: Steinar Bang [mailto:[email-masked]]
Sent: Monday, July 02, 2001 10:08 AM
To: [email-masked]
Subject: Re: WebDAV and write access discovery

>>>>> "Clemm, Geoff" <[email-masked]>:

> Probably the most general way to handle this is with the Expect
> header ... that lets the server tell you that the request will fail
> before you've sent the request body (an ACL violation is only one of
> the reasons why the request might fail).

Thanx for the tip.  Quick reference for other uninitiated:
	<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.20>

Basically, if I've understood section 8.2.3 on how to handle the
100-continue response to an expect request (link at the end of the
above section), the client should not send the body of the message
until it sees a "100 continue" response to the server.

So that would avoid me having to send the body over twice, in the case
of authentication of a PUT request, which is great. 

One thing I would like to do, is to find out if a file is writable
when I load it.  Ie. I would like to do something like:
 - GET a file
 - immediately start a PUT of the file with the expect header in place
 - if I get a "100 continue" response, set the file to be R/W,
   otherwise mark it as read-only

However, in this case the client has no intention of actually sending
the body, even if the server returns a "100 continue", and I'm unsure
of what happens if it doesn't?  Will the 1.1 pipeline be blocked?
Will a new request be taken to be an empty PUT body, and the file be
overwritten with a file of 0 bytes?

> The main problem with the Expect header is that it is an HTTP/1.1
> construct that is not understood by old HTTP/1.0 servers and
> proxies.

What's the risk with HTTP/1.0 servers in my case?  That the PUT
request with an expect header will be taken as an actual PUT request
with an empty request body, and the file get 0 bytes?

Is this a real risk?  Are there any PUT enabled HTTP/1.0 servers out
there?

---

From: Steinar Bang <[email-masked]>
Date: Thu, 05 Jul 2001 08:31:04 +0200

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

>         14.20) with the "100-continue" expectation if it does not intend

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>

---

From: Steinar Bang <[email-masked]>
Date: Thu, 05 Jul 2001 08:44:35 +0200

>>>>> Steinar Bang <[email-masked]>:

> just PUT, and then report a failure?

This link would seem to indicate that a WebFolder Visual Basic(?) 
object can return the isWritable status of a WebFolder (which is a DAV
collection...?).

So the question is then: how does it discover the isWritable status.

---

From: Steinar Bang <[email-masked]>
Date: Thu, 05 Jul 2001 08:47:14 +0200

> object can return the isWritable status of a WebFolder (which is a
> DAV collection...?).

Forgot to add the link.  Here it is:
   <http://msdn.microsoft.com/library/officedev/vbafpw10/fpobjWebFolder.htm>

---

From: Steinar Bang <[email-masked]>
Date: Tue, 10 Jul 2001 09:41:51 +0200

> 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've used cadaver against mod_dav on my laptop (SuSE 6.4 linux), and
what it uses as the <owner><href> of a lock is username@hostname
(where "username" is the name you're authenticated as, and hostname is
the name of the host withouth the domain name).

But that's mod_dav on one particular machine.  It doesn't say anything
about what another mod_dav installation might do, or what IIS does. :-/