PDF Collaboration: WebDAV In Action – Installation and Setup of WebDAV

Editor’s Note: This article is part of the PDF Collaboration: WebDAV In Action article

In general, a WebDAV server has modest hardware requirements. A Pentium
or PowerPC-based system with at least 128 MB RAM and 4GB disk space is
sufficient for the Acrobat workflow we tested. WebDAV can be installed
on most modern server operating systems, including Windows NT Server,
Windows 2000 Professional, OS X and Linux. An optimum configuration was
achieved, in our opinion, was achieved by using Red Hat Linux, Apache
and the WebDAV Extension.

The most authoritative sources of information on WebDAV, including additional
setup instructions, are WebDAV Resources (www.webdav.org),
and the IETF WebDAV Working Group (www.ics.uci.edu/~ejw/authoring/).

What follows is a reflection of our own experiences; it is not intended
as a general guide for webmasters. If you find it helpful, we’re delighted.
But you should certainly cross-check and verify these hints before starting
your installation. In particular, as new versions come along, you should
make sure that you have compatible versions of all the pieces — and
that you’ve read the newest instructions.

General Installation Notes

The end user is not normally involved in the installation of WebDAV.
But since the installation is unfamiliar, and even experienced web administrators
may struggle with its configuration, we decided to present two installation
examples here. They are based on the market-leading Apache web server
(version 1.3.20 at the time we wrote this). Linux users who have recently
installed a new Linux release can count themselves lucky: WebDAV is already
built into all new releases. If you have a new release, you can proceed
directly to ‘Configuration’ (below). If you have an older Linux release,
you’ll need Apache itself and the mod_dav module. The necessary files
are available without cost at the following Internet sources:

– Apache 1.3.20 www.apache.org

– mod_dav-1.0.2-1.3.6 www.webdav.org/mod_dav

Unix Installation for Older Releases

Like all Apache modules, mod_dav can be dynamically loaded (i.e., on
demand) or it can be statically linked to the Apache binary. To embed
mod_dav statically, the following steps are required:

cd mod_dav-1.0.2-1.3.6
./configure --with-apache=/usr/local/apache_1.3.20

(Replace /usr/local/Apache_1.3.20 with the actual directory of your Apache

make install

At this point, libdav.a is installed under the Apache source directory
and can added to Apache.

cd ../apache_1.3.20
./configure   --activate-module=src/modules/dav/libdav.a   --enable-module=dav
make install

When Apache is restarted, mod_dav is available and can be used with Acrobat.
Alternatively, if you want mod_dav to be loaded at runtime, this must
be supported by the Apache binary in use at the time, which means it must
include mod_dso. (This is usually the case with current releases of Linux.)

Then mod_dav can be converted as follows:

cd mod_dav-1.0.2-1.3.6
./configure --with-apxs=/usr/local/apache/bin/apxs

(Replace /usr/local/apache/bin/apxs with the pathname for your apxs program.)

make install

Now, the module can be loaded using LoadModule in the Apache configuration.

Loadmodule dav_module libexec/libdav.so

(Replace libexec
with the directory that actually contains the Apache module you just built.)

This installation may sound a bit complicated. Linux users and experienced
administrators will nonetheless recognize the value of the suggestions
given above.

Windows Installation

Installation under Win32 requires the Microsoft Visual C++ compiler.
Furthermore, a modified version of Makefiles for Apache 1.3.20 is required.
This is also available at the mod_dav web site.

1.) cd mod_dav-1.0.2-1.3.6
2.) nmake /f mod_dav.mak APACHE=apache_1.3.20

(Replace apache_1.3.20 with the actual directory of the Apache source.)

Now, the file Release/mod_dav.dll
(in the ‘modules’ directory under the directory containing Apache.exec) must be copied and the following line added to the

LoadModule dav_module modules/mod_dav.dll

Configuration of an Apache server

Two configuration commands in the httpd.conf
are necessary in order to use mod_dav:


This command activates mod_dav for the ‘containers’
(<VirtualHost>, <Directory>,
etc.) in which it appears. For example:

<Location /dav>
  DAV On

Additionally, it is necessary to specify a directory in which the file-lock
data can be stored. This directory must be writable by users. Furthermore,
this command can appear only once in the configuration:

DAVLockDB /usr/local/apache/var/DAVLock

Except when dealing with a test server, it generally makes sense to limit
access. Since WebDAV is merely being extending HTTP with new methods,
this can be done with Apache’s normal mechanisms:

AuthType Basic
AuthName www.server.com
AuthUserFile /usr/local/etc/users.pwd
<Location /dav>
  DAV On
  AllowOverride None
  Options None
  require valid-user

This will work, but it allows only authorized people to read the files.
Here’s a slightly fancier configuration that lets all users read the files,
but requires authorization for writing files:

<Location /dav>
  DAV On
  AllowOverride None
  Options None
  <LimitExcept GET HEAD OPTIONS>
    require valid-user

Problems Encountered

If you run the Apache ‘mod_dav’ module, the files it creates will be
written under the Unix UID of the Apache web server. Because of this possibility,
large ISPs (or managers of large extranets) must permit Web-server processes
to write to the home directory of individual clients.

Unfortunately, this situation leads to serious problems. WebDAV requires
that all directories for the user? (often named ‘www’ or ‘nobody’)?
must have file-writing rights. CGI programs, login shells, and
FTP logins of clients, however, generally run under the Unix UID of the
individual client. In order to manipulate PDF files that have been written
by mod_dav using shell logins, CGI programs or FTP, the rights of the
individual users would have to be extended so greatly that unambiguous
security between client domains is no longer provided. In extreme cases,
this would mean that clients from one domain would get full read and right
privileges to a foreign domain.

To counteract this problem, experienced Internet providers don’t implement
PHP (the most popular scripting extension for use with Linux and Apache)
as an Apache module, but rather as a CGI. Then they use the ‘suexec’ program
to help untangle the security problems.

If you use WebDAV to upload Perl scripts and other executable files,
you may encounter various platform dependencies that don’t apply to PDF
files. For example, Perl scripts must begin with the full pathname of
the Perl interpreter on a line by itself (e.g., #/usr/bin/perl followed
by a newline code. The newline code is different on Unix, Windows and
Mac operating systems. Old protocols, such as FTP, allow automatic conversion
of such platform-specific codes. WebDAV doesn’t (yet) have such a conversion
capability. If a Perl script is transferred via WebDAV, it will not run.

Even the right to execute scripts, a Unix requirement, is not automatically
awarded by WebDAV. That means a modification of either WebDAV or Apache
is necessary if you need to upload scripts for execution on the server.

You May Also Like

About the Author: Bernd Zipper

Leave a Reply