5.3 GET

One of the important design goals of WebDAV was that a Web page should be accessible in the same way via GET, with or without WebDAV functionality. The GET method does just what it always did: It downloads the Web page, image, or document. Even locks do not affect GET, because locks only affect write operations. Thus, ordinary Web browsers can browse a WebDAV site as easily as a Web site and in fact, they do not know the difference.

Like Web servers, WebDAV servers frequently support GET requests to collections. The response is usually the same: a dynamically generated HTML page with links to all the members of the collection. This is generally not attempted by WebDAV clients because the PROPFIND response can contain a much more flexible set of information and is much better suited for machine parsing.

5.3.1 Getting Collections

GET behaves the same way with WebDAV collections as it did with directories in HTTP; that is, the behavior is undefined and may vary from server to server (Section 3.1.4). This may continue to be useful for HTTP client support, but it is not likely to be useful for WebDAV clients. Instead, WebDAV clients use PROPFIND (Section 7.2.1) to get properties for a collection and to list its contents in a machine-parsable format.

5.3.2 Resource Integrity

Because a WebDAV server is likely to be used for authoring, WebDAV clients and servers must be careful to download a complete resource body more so than normal HTTP clients and servers. An incomplete or corrupted file body might be detected as soon as the file is opened. However, applications might not be capable of detecting corruption in all file types (e.g., plain text files). In authoring scenarios, an undetected corruption may not be noticed by the user either, and when the user saves his or her changes back to the server, the corrupted version is preserved.

There are a few simple ways to achieve more consistent resource integrity:

• A WebDAV server should always indicate the expected body length and never close the TCP connection uncleanly. These practices give the client extra information to check resource integrity.

• A WebDAV client should check the expected content length against the number of bytes received. If there is a mismatch or if the body length is not specified in any way, then the client might warn the user or indicate an error.

• The Content-MD5 response header [RFC1864] can contain a digest value calculated from the resource body being transmitted. If a client receives this header in response to a GET request, the client can calculate its own body digest value and compare it to ensure that the resource was correctly transmitted. If both the server and client calculate the same digest value, it's extremely likely they have the same body content. Similarly, if a server receives this header in a PUT request, it should perform the same calculation and fail the PUT request if the digest does not match.

5.3.3 How to Retrieve Source Code

Web site software usually includes support for dynamically generated pages. Sometimes these are stored in the same directories as static pages. In Microsoft IIS, for example, Active Server Pages (ASP) files are stored with internal bits of script that are executed (usually, transformed into HTML fragments) whenever the file is retrieved. Java Servlet engines supporting the Java Server Pages (JSP) specification also store dynamic pages alongside static pages.

Authoring sites with dynamic pages presents a problem: When the Web page is retrieved with a HTTP GET request, the server automatically executes the script in the page and sends the result as the response. How can the author retrieve the full source code to modify the page? HTTP presents no solution to this problem.

WebDAV solves this problem by assigning the source code one or more new URLs, each different from the regular URL for the dynamically generated page. Clients can find out the source code URLs for a given Web page by querying the WebDAV source property (described in detail in Section 7.5.9) and then request the source code using those URLs.

Changing the source code of dynamic pages is even more complicated, and the WebDAV specification doesn't resolve all issues. For example:

• WebDAV does not specify whether the resource named by the URL in the source property must be a WebDAV resource, capable of being locked and having metadata.

• There's no defined way to create a new source code file and indicate that the server should process it rather than handle it as a static page.

• It's unclear how to represent the roles of multiple source files and how they relate to or depend on each other.