WebDAV and Windows: yet another recipie


Windows has a long standing tradition making connections to WebDAV shares quite “difficult”. Bugs range from preventing use of HTTPS connections to allowing only HTTP Basic Authentication to throwing countless, weird error messages to end users (that subsequently call their admins in desperation).

At the same time you have to say that Windows is indeed the only OS suffering from such bugs, we never had a single issue connecting OS/X or any Linux box to a (correctly configured) WebDAV server.

Things have improved a bit with each new version of Windows, yet still we get support calls from customers finding their previously working WebDAV shares inaccessible after a Windows update.

So, after having fought yet another fight with the beast some days ago, I decided to publish what works for us.

The typical scenario looks like this:


So as you see, we have a front facing apache HTTPS server acting as a reverse proxy for internal resources. Among others, it reverse proxies to an internal, HTTP only apache WebDAV server, doing HTTP Digest authentication, so nothing too fancy here.

reverse HTTPS proxy configuration

Let’s begin with the “special” reverse proxy configuration. For the sake of brevity, I will neither go into details how you setup a reverse proxy in general nor how you setup HTTPS on that proxy. The apache documentation is your very friendly friend here.

<VirtualHost resources.example.com:443>
    # NOT needed, because we proxy to a HTTP only WebDAV server
    # SSLProxyEngine On
    # this is required to ensure that HTTP headers sent to the 
    # WebDAV server are "rewritten" from "https://..." to "http://..."
    RequestHeader edit Destination ^https: http: early

    # the essential proxy part
    ProxyPass /some_share http://webdav.internal/some_share connectiontimeout=300 timeout=300
    <Location /some_share>
        ProxyPassReverse /some_share
        # some WebDAV clients (such as ordinary browsers) are unhappy with the 
        # cookies sent out by the internal server, so we "rewrite" the host and
        # the used path to the correct, external representation
        ProxyPassReverseCookieDomain webdav.internal resources.example.com
        ProxyPassReverseCookiePath /webdav.internal/some_share /some_share

    # legacy windows client expect this variant of the share's URL as well ...
    ProxyPass /DavWWWRoot/some_share http://webdav.internal/DavWWWRoot/some_share connectiontimeout=300 timeout=300
    <Location /DavWWWRoot/some_share>
        ProxyPassReverse /DavWWWRoot/some_share
        ProxyPassReverseCookieDomain webdav.internal resources.example.com
        ProxyPassReverseCookiePath /webdav.internal/DavWWWRoot/some_share /DavWWWRoot/some_share

Line 8 with the RequestHeader is particularly important, otherwise some HTTP headers are incorrectly rewritten to only “https://webdav.internal/” instead of the correct “http://webdav.internal/”

WevDAV HTTP server configuration

<VirtualHost webdav.internal:443>

    Alias /some_share /huge/storage/files
    Alias /DavWWWRoot/some_share /huge/storage/files

    # we match both variants of the share name using a simple
    # regular expression. See the "/DavWWWRoot/share_name" location
    # directive in the reverse proxy for an explanation why you will
    # need this variant as well
    <Location ~ "(/some_share|/DavWWWRoot/some_share)/">
        DAV On 

        # this is vital
        DirectorySlash Off

        Options Indexes MultiViews
            AuthType Digest
            AuthName "WebDAV authentication ahead"
            AuthDigestDomain /DavWWWRoot/some_share /some_share /some_other_share
            AuthDigestProvider file
            AuthUserFile  /etc/apache2/webdav_acl
            Require valid-user

            Require valid-user

One vital part here is line 14 with the DirectorySlash off directive. Some variants of the Windows WebDAV client will strip of trailing forward slashes in WebDAV URLs, so if you map a network drive in Windows, enter “https://resources.example.com/some_share/” as the URL, it will cut off the last forward slash.

Without the “DirectorySlash off” directive the WebDAV proxy would send a HTTP 301 “moved permanently” message back to the WebDAV client, but unfortunately the redirect URL will contain the internal name of the WebDAV server:

  Content-Type:text/html; charset=iso-8859-1
  Date:Wed, 31 Mar 2015 16:32:30 GMT
  Keep-Alive:timeout=15, max=89

So in the end, your external WebDAV client will tell you that is it unable to connect to this server, which again is perfectly correct, because it very likely cannot connect to http://webdav.internal/ from the outside.

self signed HTTPS certificates

Because this problem seems to be quite common, too, a note on any self signed HTTPS certificate you might use. Technically, there is absolutely no reason to do so and from a security POV, it is the best thing you can do to guard your sensitive data.

Yet, the vital part with self signed certificates is that all clients connecting to an HTTPS server running such a self signed certificate will need to add your self created certificate authority (CA) as a “trusted CA” to the Windows certificate store.

Without that, for example Internet Explorer will at least have the kindness to warn you about a certificate issued by an untrusted source, but the Windows WebDAV client will let you die a bitchy death (sorry for that) and spit out a meaningless error message.

self signed certificates = import the signing CA to all clients connecting!

If you have come thus far, you should be able to connect any WebDAV client to your WebDAV server, but unfortunately, as time has proven many times with the Windows WebDAV client, YMMV đŸ™‚

Spread the love

Leave a Reply

Be the First to Comment!

Notify of

Post Navigation