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


From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 29 Oct 2001 22:35:27 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B104AC78FD@SUS-MA1IT01>
To: WebDAV <w3c-dist-auth@w3.org>
   From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]

   These are very good questions.

   One possible set of answers:

   > In general, I believe having distinct URL's for different resources
   > is far superior to defining new methods.  How would you set access
   > control on the "source" resource?

   The dav:readsrc privilege.

Since it is likely that the privileges for the "source" resource
will be very different from those on the "non-source" resource,
I'll also need a dav:writesrc, etc, effectively doubling the 
privilege space, just so that the server can avoid allocating a
new URL to the source resource?  In many cases, there actually
will already be a separate URL (e.g. a /xxx.jsp resource which 
generates the /xxx.html file).

Also, what about PUT?  Is an authoring client going to do a PUT to
/xxx.html in .jsp format, and then a GET will return something in
.html format?  Then what happens when a naive client tries to PUT
something in .html format to /xxx.html, and then get some unexpected
error message (or even worse, the html file will just overwrite the
.jsp resource and generate strange errors at the next GET).  Looks
like we probably should have a PUTSRC, to match the GETSRC.

   > How would you get the properties of the "source" resource?

   In this model it's not a different resource, so you'd use
   PROPFIND. If you want information about the src, then
   dav:srccontentlength, dav:srcetag, dav:srccreationdate,
   dav:srclastmodified... properties would need to be defined.

It probably would make more sense to just have a PROPFINDSRC.  And
probably a COPYSRC.  And an xxxSRC for any new WebDAV method that
could reasonably be applied to either the original resource or to the

I continue to believe that GETSRC (and its other xxxSRC friends)
would be a very unfortunate direction to pursue.  In particular,
I think having the separate URL is a clear win for clients.  I'd
be interested in even a partially compelling story from the server
vendors as to why they cannot generate additional URL's for the
source resources (or in many cases, expose the source resource URL,
when it already has its own URL).

I'd much rather do nothing here, than do something wrong.

Received on Monday, 29 October 2001 22:36:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:24 UTC