- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 16 Aug 2001 21:35:25 -0400
- To: w3c-dist-auth@w3.org
From: James Woods [mailto:woodsja@us.ibm.com] I am working on a implementaion of a webdav server. The server is going to use a database for the repository. In the database, all the resources use a unique itemid instead of the original resource name. So for example a GET www.server.com/file1.txt will have to go through a name resolver so that the database request is used with the itemid. and a PUT www.server.com/file1.txt will place this file in the database, generating a unique itemid. This is all fine, and I had planned to just create this name resolver to handle all of this, but then I was looking at the href element. I want to use the itemid as the URI for the item, and the displayname dav property to have the client show the resource name. For example, say I do a propfind on the root collection with depth 1 PROPFIND www.server.com in the properties for one of the internal members <D:href> http://www.server.com/itemid1 </D:href> <D:displayname>file1.txt</D:displayname> Now the client uses the display name to display the file in the "explorer" view, but has the href to the actual URI for requests (GET, LOCK, etc.) This is how I think these to elements were meant to be used (or at least how they could be used). Am I correct in this, or way off base? Everything is OK up to here. If I am correct about how these two elements can be used, then my next problem is with PUT and MCKOL. For example PUT www.server.com/file2.txt The argument to PUT (or MKCOL or GET or any other HTTP method) will always be a URL, not the displayname. So you would have to do the PUT to a URL with the itemid, which is a problem if you want the server to generate the dbid, rather than the client. My server would place this file in the database, generate the itemid, but.... how do I get the proper URI back to the client? You can't. PUT is required to take a URL, and required to create a resource at the specified URL, not some resource at some other server generated URL. The 201 status returned wouldn't allow me to show the client that the proper URI to request this file is actually www.server.com/itemid2 The only way the client would be able to get the proper URI for this resource is to do a propfind depth 1 on the parent collection, and this does not appear to be the case for most of the clients I have tested. I think I know how this will turn out, but I was just wondering. This is probably how you thought it would turn out. If you want to have the server generated itemid's, you are better off using the "displayname" as the URL, and if you want to expose the itemid, expose it as a server defined live property value. Cheers, Geoff
Received on Thursday, 16 August 2001 21:26:05 UTC