---last Modified on 06 Nov 2001
This FAQ is a collection of questions and answers about mod_dav contributed by the DAV community, participants of the dav-dev mailing list, and other generally knowledgeable people. This FAQ focuses on mod_dav but also covers information relating to mod_dav, mod_dav_svn, and DAV. For general questions about DAV please also see the DAV FAQ.
Information in this FAQ was taken from several sources including the dav-dev mailing list. In most cases, material quoted from the mailing list was originally in a different context such as an e-mail thread and was not written to directly answer the question here in this FAQ. The questions here were written by the FAQ authors and only present the spirit and intent of that context and are intended to increase clarity and brevity. Where possible the date and location of a source material has been noted to provide credit to members of the community and to aid in your search for more information. If there is any material in this FAQ which is not public or is copyrighted please contact the authors of this FAQ and this information will be removed.
All e-mail addresses in this document have been munged in an attempt to block spam spiders. Replace [at] with the @ symbol to un-munge the address.
Warning and Disclaimer: Some material in this FAQ is OS specific. No guarantee exists that this FAQ is correct, up to date, or even harmless.
This FAQ is copyrighted and is provided as a resource for the open source community. In that spirit it is freely available to be copied, mirrored, modified, and taken for your own use provided that full credit is given to the authors and web-dav community in all redistributions and derivative works.
The most up to date version of this document is located at http://www.sitepen.com/moddav/FAQ.html.
---Ellis Teer (teer[at]sitepen.com) on 13 Oct 2001
mod_dav is an Apache module to provide WebDAV capabilities (RFC 2518) for your Apache web server. It is an Open Source module, provided under an Apache-style license.
---Greg Stein (gstein[at]lyra.org) from webdav.org on 11 Oct 2001
The mod_dav module is located and can be downloaded from http://www.webdav.org/mod_dav/
---Ellis Teer (teer[at]sitepen.com) on 13 Oct 2001
mod_dav is Open Source software and is covered under a modified Apache style license show here http://www.webdav.org/mod_dav/license-1.html
---Ellis Teer (teer[at]sitepen.com) on 13 Oct 2001
There are a growing number of products which act as a WebDAV server or client. Some of the most commonly used client packages are Microsoft WebFolders (comes with newer versions of Windows and some Office products), Cadaver, WebDAV Explorer, and Adobe GoLive. You can find a complete list with locations at http://www.webdav.org/projects/
---Ellis Teer (teer[at]sitepen.com) on 13 Oct 2001
Newer versions of mod_dav used in Apache http 2.0 and the Subversion project use an interface which represents the collections and resources that mod_dav manipulates. Both mod_dav_svn and mod_dav_fs implement that interface. You choose which representation to use by including either one with mod_dav in your Apache configuration file. For 1.x versions of Apache you only include the mod_dav module which supports a mod_dav_fs like repository.
mod_dav_fs acts as an interface for mod_dav that allows mod_dav to store and manipulate collections and resouces as directories and files using a standard file system. By default Apache httpd 2.0 which now has mod_dav built in comes with mod_dav_fs or its equivalent.
mod_dav_svn is an interface for mod_dav that provides a CVS like repository which is based on the new Delta-V specification. It is an extension to WebDAV and useful if you need versioning control. Please see the Subversion project at http://subversion.tigris.org/ for more information.
---Ellis Teer (teer[at]sitepen.com) on 15 Oct 2001
davfs is a Linux file system driver that allows you to mount a WebDAV server as a disk drive. It is not directly related to using mod_dav and Apache as a WebDAV server since davfs can mount any WebDAV server as a disk drive. A possible configuration using davfs is to mount a mod_dav/Apache WebDAV server as a Linux disk drive.
---Ellis Teer (teer[at]sitepen.com) on 06 Nov 2001
Well, the use of @lyra.org is completely historical. At that magical point in the future, when I have all the time needed, I'd be moving dav-dev@lyra.org to mod_dav@webdav.org or something. dav-announce@lyra.org will become announce@webdav.org.
---Greg Stein (gstein[at]lyra.org) from dav-dev archive on 4 Oct 2001
mod_dav with Apache acts as a Class 1 and Class 2 WebDAV server. This means it can manipulate resources (files), resource properties, and create/remove locks on those resources to allow for exclusive control.
---Ellis Teer (teer[at]sitepen.com) 13 Oct 2001
mod_dav has a few items that cause it to be not fully compliant with RFC 2518. The cost for implementation was considered too high, and these issues are not present in typical operation. They may be fixed in some future version of mod_dav.
---Greg Stein (gstein[at]lyra.org) from www.webdav.org 13 Oct 2001
Does the WebDAV protocol support the ability to seek around in a file on the server and read an arbitrary part of it without downloading the whole thing?
Yes. See the Range: header, which is part of HTTP. (RFC 2616)
---Greg Stein (gstein[at]lyra.org) from dav-dev archive on 5 Oct 2001
DAV can be a file-sharing engine. Go look at MacOS X. It comes standard with a feature to mount a DAV server as a local filesystem, and the server version has a DAV server in it (Apache/mod_dav, actually). There is nothing in DAV that prevents it from being a remote file system. About the only features a remote file system has that DAV doesn't are *remote* authorization changes and creating symlink type functionality. The ACL draft is nearing completion and provides the former, the References draft provides the latter (but it is stalled).
---Greg Stein (gstein[at]lyra.org) from dav-dev archive on 4 Oct 2001
Apache and mod_dav are quite secure. There has not been a single reported exploit of the code in the past three years (when it was first released). You can misconfigure your Apache/mod_dav system (in fact, SuSE Linux released an RPM like this and had to issue a security advisory and upgrade). But given that you take the precautions listed in the installation document, Apache and mod_dav are quite secure.
---Greg Stein (gstein[at]lyra.org) from dav-dev archive on 4 Sep 2001
Currently there are no quota facilities built into mod_dav. It would be difficult to do this while remaining platform independent because each operating system handles quotas differently. However, adding user and quota management independently into mod_dav has been discussed. Although no plans are currently in the works any user and quota management done by mod_dav would be in addition to the operating system and would not necessarily work in conjunction with it.
---Ellis Teer (teer[at]sitepen.com) on 19 Oct 2001
While mod_dav itself doesn't have the capability to support a traditional quota system, you can have apache run under each user's account, thereby supporting it. Note that this requires apache to run as root, so think again before you do it.
Well, first of all, you'll need to recompile apache with -DBIG_SECURITY_HOLE flag set in CFLAGS. This will allow you to run apache as root, so it can later submit seteuid(2) call using authorization result.
# As the name implies, this can lead to serious problem, but
# I guess you can accept the risk.
After recompilation is done, you have to decide how you want username (taken from web-based auth) to be mapped to uid on your system.
If you just want username to be mapped to uid based on /etc/passwd, you should be OK just by installing mod_become available from http://www.snert.com/Software/Become/
If not, you'd have to write your own apache module, so apache will submit seteuid(2) call for proper uid mapped from given username. This itself is trivial, and you'd just have to take care of two points:
Code fragments will look like this:
/* * in fixup stage */ /* find uid for given username - this must be written by yourself */ uid_t uid = mygetuid(username); if (uid == 0) uid = uid_for_some_safe_user; /* Don't handle request as root */ seteuid(uid); ... /* * in logging/cleanup stage */ seteuid(ap_user_id); /* Regain superuser privilege for next seteuid(2) */
In case you have mod_perl or similar modules, This could be written in one-line hack. All you need is to hook into PerlFixupHandler and PerlLogHandler, modifying value of $>.
---Taisuke Yamada (tai[at]iij.ad.jp) from dav-dev archive on 23 Mar 2001
Please see this link http://www.webdav.org/mod_dav/install.html
---Ellis Teer (teer[at]sitepen.com) on 10 Oct 2001
These instructions assume that you are building the Apache web server with mod_dav from scratch. To add the mod_dav module to an existing Apache server, follow the installation instructions provided in the mod_dav documentation. Building Apache and mod_dav requires the GNU gcc compiler, which can be obtained in binary form for several platforms (http://www.gnu.org/software/gcc/gcc.html).
Designate a file partition where your Apache web server with the mod_dav module will reside and create a top-level directory under this partition for the data server named "www" or something similar. For example, we installed our server under a top-level directory
/myfiles1/www.
prompt% cd /myfiles1
prompt% mkdir www
prompt% cd www
Download the following products into the src directory:
Apache version 1.3.20: http://httpd.apache.org/dist/httpd/apache_1.3.20.tar.gz
mod_dav version 1.0.2: http://www.webdav.org/mod_dav/mod_dav-1.0.2-1.3.6.tar.gz
Gunzip and extract files from the Apache and mod_dav distributions:
prompt% gunzip apache_1.3.20.tar.gz
prompt% tar xvf apache_1.3.20.tar
...
prompt% gunzip mod_dav-1.0.2-1.3.6.tar.gz
prompt% tar xvf mod_dav-1.0.2-1.3.6.tar
...
Run the "configure" command for Apache:
prompt% cd apache_1.3.20
prompt% ./configure --prefix=/myfiles1/www/apache_1.3.20
...
Run the "configure" command for mod_dav:
prompt% cd ../mod_dav-1.0.2-1.3.6
prompt% ./configure --with-apache=/myfiles1/www/apache_1.3.20
...
Build the mod_dav module:
prompt% make
...
prompt% make install
...
A second "configure" command is given in the Apache source code tree in order for mod_dav to be installed as a web server module:
prompt% cd ../apache_1.3.20
prompt% ./configure --prefix=/myfiles1/www/apache_1.3.20 --activate-module=src/modules/dav/libdav.a
...
Build the Apache web server with mod_dav:
prompt% make
...
prompt% make install
...
---Eric G. Stephan (Eric.Stephan[at]pnl.gov) on 10 Oct 2001
Once you have installed your Apache web server with a mod_dav module and you have set up your user account file you must finish setting up your server by editing the Apache httpd.conf file. This is found in your Apache installation "conf" directory. These instructions represent a minimal configuration just to get you started. Note: It is a good practice to make a backup of your httpd.conf file before making any editting changes.
A few things you should know about the the httpd.conf file:
In a text editor make the following changes to your httpd.conf file:
# This should be changed to whatever you set DocumentRoot to.
#
<Directory "/files0/home/e-wwwdocs">
#
# This may also be "None", "All", or any combination of "Indexes",
# "Includes", "FollowSymLinks", "ExecCGI", or "MultiViews".
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
Options Indexes FollowSymLinks MultiViews Includes
#
# This controls which options the .htaccess files in directories can
# override. Can also be "All", or any combination of "Options", "FileInfo",
# "AuthConfig", and "Limit"
AllowOverride None
#
# Controls who can get stuff from this server.
#
Order allow,deny
Allow from all
</Directory>
# --
# -- Default Directives for access control and other features start here.
# --
# The top level DAV directory
# Here we turn DAV on, allow web browser access, and enable only read
# operations. The application realm name can be called anything that pertains to your application..
<Directory full-DAV-directory-path>
AuthName "any-name-you-want"
AuthUserFile directory-path-to-password-file/password-file-name
AuthType Basic
AllowOverride None
DAV On
Options Indexes
Order allow,deny
#Example of a default read only access for general user community.
#You can handle the rest of authorization through .htaccess files.
Allow from all
<Limit HEAD GET POST OPTIONS PROPFIND>
Allow from all
</Limit>
<Limit MKCOL PUT DELETE LOCK UNLOCK COPY MOVE PROPPATCH>
Deny from all
</Limit>
require valid-user
</Directory>
---Eric G. Stephan (Eric.Stephan[at]pnl.gov) on 10 Oct 2001
The same way it restricts access to any other document served by Apache -- through standard Apache authentication such as .htaccess files. mod_dav has no built-in authentication, it doesn't need any -- other Apache modules handle all of that (including SSL encryption if you want it). Note that Apache auth (and hence mod_dav) has nothing to do with your standard Unix users and passwords in /etc/passwd -- this seems to be a common misconception.
---Brendan Quinn (brendan[at]clueful.com.au) from dav-dev archive on 11 Oct 2001
Given that mod_dav is just that (an apache module) you will find this.... tricky (to say the least). Apache can only write files according to unix file permissions as the user the server runs as (generally 'nobody'). Your current options (as I see them) are:
1) Compile apache with -DBIG_SECURITY_HOLE and run it as root, thereby allowing apache to setuid as needed. This is, of course, a Bad Thing(tm) to do.
2) Run an apache instance as each user who will be accessing the system. This would be a tad annoying to implement, but not impossible. It really depends on how many users you have accessing the system. If it's a small-ish installation (< 100 users), I don't think it would be that difficult to have a small program listening on port 80 which wil take incoming requests and fire up "httpd -c username". I can think of two ways to grab the necessary username from an incoming request. This is not what I would necessarily consider ideal either, but it would be interesting to implement.
3) Write/find a DAV server CGI and run it under suexec. I don't know if such a beast exists, but it would solve your problems as well. If course, you take fork() penalties at this point, so performance may become an issue, depending on your projected traffic.
---Noah Robin (sitz[at]onastick.net) from dav-dev archive on 1 Oct 2001
A utility called "htpasswd" is provided in your Apache installation bin directory for managing user accounts. In a nutshell, htpasswd simply creates password files and adds user names and encrypted passwords to the file. To list all of the options for the utility:
prompt% htpasswd -?
To create a password file:
prompt% htpasswd -c /my-directory-path/my-password-file user-name
Note: You will be prompted to enter the same password twice.
To add additional user accounts to the password file:
prompt% htpasswd /my-directory-path/my-password-file user-name-2
Warning: For security purposes it is recommended that you do not store your password file under your Apache web root.
---Eric G. Stephan (Eric.Stephan[at]pnl.gov) on 10 Oct 2001
mod_dav doesn't come with any utilities for manipulating the lock file (except through WebDAV itself). But you *can* simply blow away all locks by removing the .dir and .pag files. But be forewarned: that could very well remove locks that somebody else is expecting should be there. Some DAV clients do not respond well to having their locks disappear/timeout. (MS Office for one) The recommended approach is just to call it administration downtime. Tell your users that you'll be down for a minute and they should save/close their work, then just go and delete the lock files. (note that you don't have to shut down apache for this)
---Greg Stein (gstein[at]lyra.org) from dav-dev archive on 4 Oct 2001
"The client has to issue the lock request. Office and other clients user lock, but Webfolders does not. "
---Keith Wannamaker (Keith[at]Wannamaker.org) from dav-dev archive on 11 Sep 2001
mod_dav does not display symbolic links and ignores them when found. Symbolic links are not defined in RFC 2518. Note that the repository or in this case the file system should be private to mod_dav and since mod_dav cannot create symbolic links you should not have any symbolic links unless you created them manually or with another program. If you are manipulating the repository manually while mod_dav is running be careful as you are circumventing mod_dav's file locks and could potentially cause problems.
---Ellis Teer (teer[at]sitepen.com) on 15 Sep 2001
If you are using Microsoft WebFolder, it apparently has an incompatiblity bug that it sends in filename in unknown platform-local encoding instead of UTF-8 (This seems to have been fixed in some latest release, but still have not verified which exactly is the one). It is also known that many UNIX-based implementation to behave the same way.
While mod_dav does not allow encoding other than UTF-8, there's a patch to mod_dav and separate apache module (mod_encoding) to address this situation. The module is available from http://www.lyra.org/pipermail/dav-dev/2001-May/002428.html It is currently under major enhancement, and updated version should be available sometime soon.
---Taisuke Yamada (tai[at]iij.ad.jp) on 19 Oct 2001
There's a patch currently under development that will allow mod_dav to handle server-side encoding other than UTF-8 (this one is different from the Microsoft WebFolder UTF-8 patch). By coordinating this patch with the WebFolder UTF-8 patch, you would be able to use whatever encoding you like to use, both on client-side or server-side.
One of the earliest implementations can be found at http://www.sera.desuyo.net/WebDAV/ for Japanese encoding. And there's a team working on to integrate several available implementations to support all encodings used worldwide (also has major improvement in Japanese support).
This should be available sometime soon.
---Taisuke Yamada (tai[at]iij.ad.jp) on 19 Oct 2001