========================= WebDAV Support in Orenosp ========================= When using "proxy_pass_by = url" mode ===================================== Because of WebDAV protocol, you have to use the same path for both reverse proxy and backend WebDAV server. Let's say you want to publish resources under http://iis-host.internal/davdir (internal host) via a reverse proxy https://www.example.com/. Then the reverse proxy must publish them under https://www.example.com/davdir. proxy_pass_by = url lis-ssl://*/davdir https://iis-host.internal/davdir Please be aware that you cannot put '/' at the tail of either path specifications when proxying WebDAV. Reverse-proxying IIS DAV ======================== General ------- Although most of Windows server and client products support WebDAV file sharing protocol, there are many limitations, interoperability problems and quality issues in the WebDAV of IIS as well as Microsoft's client side WebDAV implementations, which prevent their use in many distributed environments. Specifically, most combinations work great in a LAN environment, but many fail to work in a distributed environment where network access is restricted by various intermediary devices like firewall and proxies. This tendency is not only present in WebDAV but also in other Microsoft technolgies and products. One notable problem is the Windows integrated authentication system, which simply fails to work in presence of HTTP proxies. One of th Orenosp's goals is to make it possible to deply the great Microsoft network related products in many distributed environments. However if you wish to have most trouble-free configuration, I suggest you choose other technolgies for file sharing solution over the Internet: - FTP over SSL : recommended for heavy-use file transfer needs => Orenosv has FTPS service - HTML over HTTPS : "browser-based" file sharing => Orenosv's HTML Files Application, plus Orenosp HTTPS reverse proxy IIS WebDAV Problem ------------------ Behavior of IIS WebDAV module makes it difficult to deploy behind a reverse proxy. Unlike the original HTTP/1.1, WebDAV utilizes a message body as container for WebDAV metadata. The problem is that IIS WebDAV embeds in these WebDAV message bodies absolute URLs that point to its own resources. Also there seems to be no option to change this behavior. This is true for IIS 5.0 and 6.0. example: PROPFIND /davdir HTTP/1.1 HTTP/1.1 207 Multi-Status --- message body --- ... http://iis-host.internal/davdir/ ... http://iis-host.internal/davdir/file1.html ... --- end of message body --- This poses a serious problem when a DAV client tries to access these URLs because they are relevant only in the intranet. Apache mod_dav, on the other hand, uses relative URLs to point to its own resources: /davdir/ ... /davdir/file1.html ... ---quote from http://www.webdav.org/mod_dav/ --- mod_dav responds with relativeURI values in the element. The URIs are relative to the host. For example: /some/path/somefile.html. Some other servers return absolute URIs. --- Most reverse-proxies are able to rewrite absolute URLs found in HTTP headers, but not many of them can rewrite URLs in WebDAV message bodies in 100% correct way. Solution (Orenosp 0.8.0 or later) --------------------------------- proxy_pass_by parameter now has an option: -rw_dav=1 This option will enable automatic rewriting of message bodies of WebDAV requests and response. You might also need to increase value for the parameter: proxy_post_save_limit = 65536 Note that you can also specify -rw_url=1 at the same time. "-rw_url" applies to HTML documents, whereas "-rw_dav" only applies to WebDAV XML messages. Workaround ---------- Give the same virtual hostname ("Host header for Web Site" in IIS terms) to the IIS as that of the public orenosp proxy. If your public orenosp has www.example.com as a virtual host, create a new "Web Site" having "www.example.com" host header on the internal IIS. Also make the "Web Site" listen on HTTPS port of 443 if your orenosp listens on HTTPS. Then use the following proxy_pass_by rule in sproxy.conf: proxy_pass_by = vhost www.example.com https://iis-host.internal/ \ -hh=www.example.com Or if you want to offer resources under a specific path only, you can do: proxy_pass_by = url lis-ssl://*/davdir https://iis-host.internal/davdir \ -hh=www.example.com (you could also use -hh=_self_ instead) Configured in this way, IIS will generate URLs to its own resources as https://www.example.com/... and at the same time the clients will use the same URLs to access the reverse proxy. This approach is difficult to take if you already have a Web Site that utilizes SSL. This is because IIS may not allow you to have more than one Web Sites listen on the 443 port. WebDAV Client-side related -------------------------- On XP SP1, the explorer uses kernel-level WebDAV redirector for HTTP sites and it uses a user-level WebDAV DLL for HTTPS sites. XP SP1 HTTP: Microsoft-WebDAV-MiniRedir/5.1.2600 HTTPS: Microsoft Data Access Internet Publishing Provider DAV 1.1 These two behave differently in some aspects. One thing I noticed is that the mini-redirector uses UTF-8 for URL but the dll uses native character set (e.g., SJIS). Related Information on WebDAV ============================= WebDAV Mini-Redirector (MRXDAV.SYS) Versions and Issues List http://greenbytes.de/tech/webdav/webdav-redirector-list.html Web Folder Client (MSDAIPP.DLL) Versions and Issues List http://greenbytes.de/tech/webdav/webfolder-client-list.html EOF