Subject: WebDAV and write access discovery

From: Steinar Bang <[email-masked]>
Date: Fri, 29 Jun 2001 10:47:11 +0200

I have implemented HTTP read and write for a tool (the METIS modelling
tool <http://www.metis.no/products/what_is_metis.html>).  The main
issue with doing write over HTTP, was determining if a file was
read-only, or read/write when loaded.

Basically the only way I found, was to set all files loaded over HTTP
to be read-only initially, and to provide a toggle command that allows
the user to make a file loaded over HTTP be read/write (with warnings
that changes made may be lost), and then try to save.

If the files being saved are of megabyte size, this is a slow and
wasteful approach.

So what I hoped to get from WebDAV, was a way to check if the user
given by the authentication scheme has write access to a particular
file.  However, when I read the WebDAV documents I couldn't find
anything in the XML format described, that held the information I
needed.

I figured that this might be because I was too stupid to understand
the specification, and I didn't want to embarras myself by asking a
question that was obvious to everybody on this mailing list. :-)
So I kept quiet and walked away.

Recently I've returned to the WebDAV docs, and I've discovered 
	<http://www.webdav.org/acl/>
and concluded that the reason I didn't find it, was that it wasn't
there to find when I looked...:-)

But then my question is: people have been layering webdav over file
systems since back in 1998 or thereabouts (mod_dav is a prime
example), and people have been running explorer-like tools against
WebDAV servers for as long.

And the explorer like tools would have need to have knowledge about
the stuff that WebDAV ACL provides.  So what have they done when it
was missing?  Using custom properties would give uninteroperable
solutions.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 29 Jun 2001 09:41:06 -0400

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).  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.

But I'd encourage client writers to use the Expect header to
optimize this situation (with suitable timeout
guards to handle 1.0 servers).  This will help motivate everyone
to replace their 1.0 servers with 1.1 servers (making things run
faster is always a good motivator).

Cheers,
Geoff