- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Mon, 24 Jan 2000 09:53:46 -0800
- To: falk@excosoft.se, w3c-dist-auth@w3.org
> I have a WebDav / Http url problem. The problem I have, as a > client developer, is to know when to do a propfind directory > browsing and when to just do a get. > An example: > The user types that he wants to open 'http://www.foo.com/foo'. If > /foo is a directory there is a problem. If I do a get on that url, > the server could hand me /foo/index.htm ( or some other default > file ), or it could generate a html file displaying the directory > listing. But if I do a propfind, I could generate a directory > listing from the answer. > > But how can I know which the users wants? One solution is this: If you don't know whether it is a collection, or an ordinary resource, always perform a PROPFIND of Depth 1 on the resource. If the resource is a collection, you'll receive the directory listing. If the resource is an ordinary resource, you should just get back the properties on the resource itself, which will be a fairly small response. Then, if it is just an ordinary resource, you can proceed with the GET. Note that this would only need to be done when the program doesn't know what kind of resource it is dealing with. Once the program starts receiving PROPFIND responses, it can cache that information, and check its cache before performing the request. While the program shouldn't depend on the cached information being correct (it could be stale), you can certainly make some optimizations based on the expected type of the resource (for example, going straight to a GET request if you expect the resource is an ordinary resource). > Today I solve this by using a wildcard at the end of the url. > Ex: > 'http://www.foo.com/*' -> Do a propfind on 'http://www.foo.com/'. > If not okay, try a Get on 'http://www.foo.com/*'. > This gives the user a way of 'open as webfolder', without having > to checking a checkbox. So now you can have links in xml files, > that gives you a WebDav directory listing. Or even email it. My concern with the "*" approach is that most non-programmer types don't realize there are special wildcard semantics associated with "*". - Jim
Received on Monday, 24 January 2000 12:57:52 UTC