4.2 URLs and WebDAV Resources

Every WebDAV resource has an HTTP URL. Since WebDAV resources are also fully compliant HTTP resources, the same URL allows access for both ordinary Web browsers and WebDAV clients. The WebDAV client can discover WebDAV support by querying the resource with OPTIONS.

Figure 4-2 shows a simple WebDAV URL. It is also an HTTP URL; in fact, it is the same as the URL shown in Figure 3-1 in Chapter 3, HTTP Mechanics. The only difference is that now the client can interpret even more of the URL.

Figure 4-2. A simple URL.

HTTP treats the path part of the URL as an unstandardized string: Clients theoretically cannot make any assumptions about how the server handles or interprets the path /hr/index.html. In WebDAV, however, the path part of the URL includes the name of the resource and the collection hierarchy in which it appears. This was a de facto construction for most HTTP servers, but WebDAV makes it mandatory.

Collection names are separated with the forward slash (/) character. Each collection must be the parent of the collection or resource that appears after it in the URL. A WebDAV-compliant URL ending in a slash always refers to a collection (but not all collection URLs end in a slash).

Backward Slashes

Forward and backward slashes (/, \) are sometimes treated as synonyms in HTTP URLs. The backward slash is not allowed in URLs, but Windows users may be in the habit of typing backward slashes anyway. Client software may accept backward slashes users type in, but the software must convert to forward slashes before sending URLs in protocol messages.

4.2.1 Root URL

A WebDAV repository usually has some kind of root collection that contains all other collections. Of course, the root does not have a parent collection. A successful request to the repository's root URL should show that it is a collection and that it supports WebDAV.

Often, the URL to the root of a repository consists of the server URL and a path consisting only of /. For example:

http://www.example.com:8080/

In some cases, however, the root of the repository may include a path element. This method may be used at sites where several Web services are hosted, including perhaps regular Web files and other services as well as a WebDAV repository. The only way for this server to know when the WebDAV repository is being addressed is to include some string in the path to indicate which hosted application to address.

http://multiapp.example.com/davdocs/

On this server, the path / is unlikely to be a WebDAV collection.

4.2.2 Path Hierarchy

After the WebDAV repository root, the URL path may have a number of collection names and finally may contain one file name. If a repository has two collections for two different departments, appearing right under the root directory, these might appear as:

http://www.example.com/hr/

http://www.example.com/finance/

Inside the hr collection is a default Web page and a few more collections.

http://www.example.com/hr/index.html      file
http://www.example.com/hr/ergonomics/     collection
http://www.example.com/hr/benefits/       collection
...

The hierarchy that these addresses correspond to can be drawn without any further information (see Figure 4-3).

Figure 4-3. Hierarchy based on URL structure.

In this example, every resource we've shown is a collection, except for index.html. The client browsing this repository can tell what's a collection and what's not with the DAV:resourcetype property that exists on every resource.

4.2.3 URL Uniqueness

It is very common to see multiple URLs refer to the same Web resource. The classic example of this is a site with daily news or a daily comic, where on August 15, the page today.html is the same page as aug15.html, but on the following day, today.html is the same page as aug16.html.

WebDAV does not explicitly deal with multiple URLs to a single resource. If a server is configured so that the two URLs aug15.html and today.html bind to the same file [Clemm03], clearly a GET request to each URL will return the same content body. Other operations aren't so evident, and since WebDAV doesn't deal with multiple bindings, there is no required behavior. For example, the server must decide whether locking one URL will cause the other URL to also be locked.

It's also possible for one URL to refer to multiple resources. The page userguide.doc might have both French and English variants (variants are defined in RFC2616), both stored and mapped to the same URL. WebDAV does not deal with this issue, either. HTTP defines how the server knows which resource to return in response to a GET request, but there's no way to know how to author one of them using WebDAV. The WebDAV Working Group has discussed whether to address this topic, but more important features have come up so far.