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 source.)
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=davmakemake 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.)
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.
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.62.) 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 httpd.conf:
LoadModule dav_module modules/mod_dav.dll
Configuration of an Apache server
Two configuration commands in the httpd.confare 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</Location>
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:
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 BasicAuthName www.server.comAuthUserFile /usr/local/etc/users.pwd<Location /dav> DAV On AllowOverride None Options None require valid-user</Location>
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 </LimitExcept></Location>
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.