5.1 WebDAV URLs and Feature Discovery
| WebDAV uses HTTP URLs, but there are some differences in what the URLs mean to the client. This topic is intimately tied to feature discovery, so I've combined these two considerations, including how WebDAV extends the OPTIONS request and response. 5.1.1 Discovering WebDAV SupportUsually, the client software starts out with a URL typed in by a user, sent in email, or linked from another Web page. Starting with just a URL: http://example.com:8080/hr/ergonomics/posture.doc This is obviously an HTTP URL and a HTTP resource, but how can the client know if it's also a WebDAV URL and a WebDAV resource? The client needs to be able to find out in order to know if the server will accept methods like MOVE, COPY, PROPFIND, and PROPPATCH on that URL. The client can discover this through the OPTIONS request and response, as shown in Listing 5-1. Listing 5-1 OPTIONS on a WebDAV resource.Request: OPTIONS /hr/ergonomics/posture.doc HTTP/1.1 Host: www.example.com Response: HTTP/1.1 200 OK Date: Mon, 30 Jul 2001 00:30:15 GMT Server: Apache/1.3.14 (Unix) DAV/1.0.2 DAV: 1,2 MS-Author-Via: DAV Allow: OPTIONS, GET, HEAD, DELETE, TRACE, PROPFIND, PROPPATCH, COPY, MOVE, PUT, LOCK, UNLOCK Accept-Ranges: bytes The DAV header indicates that this resource supports WebDAV. It shows whether the server supports WebDAV Class 1 features alone or both WebDAV Class 1 and 2 features. The DAV header contains comma-separated values, where the value 1 indicates Class 1 support, and the value 2 indicates Class 2 support. All WebDAV servers are required to support Class 1, which covers everything in RFC2518 other than locking. Class 2 includes locking as well. We have already looked at a couple of these headers. The Allow header shows all the methods supported by the resource (Section 3.7.2), and the Accept-Ranges header shows that the server can accept byte-range requests (Section 3.7.12).
5.1.2 URLs to CollectionsAll WebDAV collections have URLs as well, very much like ordinary resources. WebDAV specifies that collection URLs end with a slash character (/ ). Although servers generally accept incoming collection URLs that do not end in a slash, servers should always generate collection URLs that do end in a slash. http://example.com:8080/hr/ergonomics/
Just as with a regular resource, a WebDAV client must use an OPTIONS request to find out if a URL ending in a trailing slash points to a WebDAV resource, as shown in Listing 5-2. Listing 5-2 OPTIONS response for a WebDAV collection.HTTP/1.1 200 OK Date: Sat, 27 Oct 2001 19:16:54 GMT Server: Apache/1.3.19 (Unix) DAV/1.0.2 MS-Author-Via: DAV Allow: OPTIONS, PUT, LOCK, PROPFIND, PROPPATCH, UNLOCK, DELETE, MOVE, COPY DAV: 1,2 Based on this response, the client can be sure that the resource exists and is a WebDAV resource, but there's nothing reliable to prove that the resource is a collection. The client should not rely on the format of the URL or on the OPTIONS response to determine if the resource is a collection. WebDAV allows servers to omit the trailing slash, so the URL is not a reliable indicator. The Allow header value might be a more reliable tool, but servers differ slightly in the methods they advertise in this header for a collection. The official way to tell if a resource is a collection is to use the resourcetype property (see Section 7.5.8). 5.1.3 Deconstructing WebDAV URLsSince the path part of a WebDAV URL follows some well-defined rules (unlike the path part of an HTTP URL), clients can use those rules in reverse to figure out other valid URLs that may also be WebDAV resources. The only reliable way for a client to discover the parent of a given resource is by parsing its URL. Imagine that the user clicks on the following link in email or on a Web page, and the WebDAV client has no prior knowledge of the resources on this server: http://example.com:8080/hr/ergonomics/posture.doc The client can discover that /hr/ is a WebDAV-compliant collection by querying its properties. Once it knows that, the client can deduce further facts:
Now the client knows about three different resources on the WebDAV repository and can make behavioral predictions. For example, a list of the children of /hr/ergonomics/ will include posture.doc. If posture.doc is then deleted or moved to another collection, then /hr/ergonomics/ will no longer contain posture.doc. One result of the WebDAV URL rules is that every operation that affects the name or parent collection of a resource also changes its URL. We'll see shortly how the MOVE method can be used either to rename a resource or move it to another directory, both of which will alter the URL of the resource. 5.1.4 Limits to HTTP URL DecompositionIt's important to remember that some elements in the path of a WebDAV URL may not be WebDAV collections. Some of the early parts of the path might have another meaning to the server. For example, a WebDAV server can be implemented using the Java servlet engine. Servlets are often configured to use addresses of the form: http://example.com/servlet/servlet-name The path fragment servlet is an instruction to the Web software to invoke the servlet engine, and the fragment servlet-name is an instruction to the servlet engine to run a particular servlet. Let's say a WebDAV servlet is configured as: http://example.com/servlet/dav If that URL points to a regular Java servlet, then the client can query a number of different URLs to see if they are WebDAV collections. Table 5-1 lists what the client finds. Sometimes administrators want to use the same server or hostname to host multiple applications. For example, a server called multi.example.com may host several HTTP hierarchies with different functionality:
Unfortunately, early releases of Windows XP had a serious problem decomposing WebDAV URLs. When a WebDAV repository is mapped to a drive letter using the Windows XP WebDAV drivers, the repository root must respond as a WebDAV resource. Given a URL such as http://example.com/servlet/dav/accounting/, the XP software immediately does an OPTIONS request to http://example.com/. If that URL does not appear to support WebDAV, then Windows XP fails the mapping request, even though the URL it was originally given would show WebDAV support if it were queried. The next section explains how a client like Windows XP should behave. 5.1.5 Finding the Repository Root with OPTIONSClient software sometimes attempts to find out the root of a repository. This could be desirable in order to cache server feature support information, cookies, or authentication information or to be able to mount the root of the repository once rather than have to mount separately a number of collections deep in the repository. A naive approach to this problem would be to assume that the root of the repository is the root path element, or /. However, as we've just shown, that can fail. If a client must find the top-most directory that supports WebDAV, it may have to try every element in the path. Given the following URL: http://example.com/servlet/dav/accounting/index.html then the recommended approach to determining the root of the repository is to work up the collection chain and use OPTIONS requests to find out which elements are WebDAV collections. Each time, the client should check the OPTIONS response to make sure that the resource responds and that it supports WebDAV. (Although PROPFIND could theoretically retrieve the same information and more, it's not as reliable, because PROPFIND may be subject to more permissions restrictions than OPTIONS requests.) In this case:
|
EAN: N/A
Pages: 146