RE: Last Call: Access Control Protocol

>  2) This protocol has departed from the Web interface of access
>     control being set on a per-method basis.  The effect of this
>     change is that access control will now have to be governed
>     by both the Web server and whatever handler within the Web
>     server is interpreting WebDAV methods, resulting in a
>     pointless duplication of code (and effort, if the resource
>     requires both forms be active).  Eventually, someone will have to
>     define an HTTP access control protocol.

In a file-based Apache installation, reading a particular resource requires
that GET is enabled, and that read permissions are set on a specific file.
So, in stock Apache, the read operation is governed by both the "Web server"
and the code interpreting the GET method. The DAV ACL protocol is the same.

Our goal was to create an access control protocol for remote collaborative
authoring of Web resources, not a remote Web server configuration protocol.
There was room for consensus on the former, not on the latter.

>  3) The protocol does not differentiate between writing to a
>     resource (PUT) and appending to a resource (POST), and
>     thus cannot be used to control shared access for things
>     like guest-books, log files, or collection-like bulletin
>     board resources.

If you can identify a single DAV client that uses POST to append to a
resource, I might consider this a valid case that should be accommodated by
the protocol.

At present, POST is almost exclusively used for forms submission and
HTTP-tunneled RPCs of various types.  We felt that each individual use of
POST (i.e., each RPC scheme) would require one or more privileges to be
defined for them. We didn't want to guess, a priori, as to which privileges
they might need.

- Jim

Received on Monday, 12 November 2001 13:26:46 UTC