| WebDAV request operations are HTTP/1.1 requests with the same structure and protocol/version field but new method strings. The WebDAV designers could have gone with an approach like that taken by SOAP [Box00], which also extends HTTP, but where all requests are made using the same method (POST). There are advantages and disadvantages to each approach, and the advantages depend on the application. The advantages to defining new methods for WebDAV: It's easy to filter for WebDAV requests by looking for the method name. This puts security more firmly in the hands of network administrators. HTTP access controls may be based on the method; for example, a user may have permission to do a GET but not a PUT. WebDAV works nicely with access control by defining new methods for operations that may have different permissions. It's easier to define body types, headers, and errors for new methods, rather than specify how new body types and new headers interact with old methods and old headers.
The primary disadvantage to defining new methods is that firewalls and proxies may block methods other than those defined in HTTP/1.1. WebDAV implementors have also found that some legacy Web application servers don't support new methods, making it difficult to implement a WebDAV server using those application servers as a platform. However, recent firewall, proxy, and application server releases tend to do a better job of handling new methods. If you find yourself in a situation where the WebDAV methods are blocked or not supported by existing software, it's possible to tunnel the requests. Two basic approaches have been shown to work: If a firewall is blocking the WebDAV methods, try tunneling through the CONNECT request [RFC2817]. The CONNECT request allows Web browsers to make SSL and TLS connections to Web servers outside the firewall, even if the firewall only supports port 80 [Rescorla01]. This mechanism only tunnels through the firewall on the client's site when the client initiates the request. CONNECT allows clients to tunnel out, not in. If an application server does not support WebDAV requests from clients, put a trivial filter program in place before the request reaches the application server. This filter can replace the WebDAV request method with POST and insert a custom header specifying the original request method. After the application server passes the POST request to the WebDAV software, the original method can be recovered from the custom header.
These workarounds are less and less necessary as WebDAV becomes more widespread and better supported. |
