mod_dav: a DAV module for Apache

mod_dav is an Apache module to provide DAV capabilities (RFC 2518) for your Apache web server. It is an Open Source module, provided under an Apache-style license. This page serves as a distribution point, as documentation, and as a FAQ for mod_dav. Updates, clarifications, questions, etc, are gratefully accepted at [email protected].

A FAQ for mod_dav is being developed and is now available.

mod_dav 1.0 was released on June 13, 2000. Please see the press release for related information.

More information about DAV can be found on the WebDAV Resources site.

How do I get mod_dav?

Right here. The current version is 1.0.3 and has been built and tested against Apache 1.3.x on a Linux system. Other Unix(-like) platforms should not have a problem with mod_dav. There is a separate page for mod_dav on the Win32 platform.

http://www.webdav.org/mod_dav/mod_dav-1.0.3-1.3.6.tar.gz

mod_dav prefers to build against Apache 1.3.6 or later, but it is possible to use it with Apache 1.3.4. Earlier versions are not supported at all, since it is not possible to deploy a secure DAV server unless you use 1.3.4 (the Limit configuration directive is not available for DAV methods in prior versions).

The configuration, compilation, and installation instructions are included with the distribution and are available here for reference. If you're familiar with Apache, then you shouldn't have a problem. The install instructions also cover how to enable the DAV module in your Apache setup.

Problems with your installation? If the above instructions do not help, and you still have problem, then see this section of the installation documentation.

There is a mailing list where I'll be sending announcements about mod_dav releases (and possibly other, important related announcements). Visit the dav-announce list information page to subscribe.

A second mailing list for users and developers is available. Visit the dav-dev list information page to subscribe.

Please note the licensing section below.

You may also need the following packages:

• Expat: James Clark's Expat XML Parser

  James Clark has written an excellent XML parser which is used from the C interface level.

  This parser is directly included with Apache 1.3.9. If you have a previous version of Apache, then you will need to fetch a copy of Expat yourself and build it. Directions for building Expat (you'll need to make a minor change to its Makefile) are in mod_dav's INSTALL file. You can fetch the parser itself from his Expat pages.

• Optional: GDBM: GNU Database Manager

  By default, mod_dav uses SDBM to store its properties. You can choose to use GDBM instead, by editing dav_fs_dbm.c and linking against the GDBM library.

  This is readily available on most systems. I've been working on a Linux system, and it is simply a part of my RedHat distribution. For other systems, GDBM can be retrieved from:

  ftp://prep.ai.mit.edu/pub/gnu/gdbm-1.7.3.tar.gz

mod_dav is available through anonymous, read-only CVS. Please see the instructions for more information. The CVS archive is also available through your web browser.

mod_dav on Win32

mod_dav works natively on the Win32 platform. Please see the separate page for more information.

Some other options for Apache and mod_dav on Win32 include:

• Use mod_dav in the cygwin environment. Please see the CAMP distribution for a precompiled binary.
  Note: as of June 11, 2000, it appears that CAMP uses mod_dav 0.9.8
• Use commercial products such as CyberTeams WebSite Director, or Microsoft's Internet Information Server (IIS) from Windows 2000 (NT5). These products support DAV. Links and additional information are on the Projects and Software page.

Tell me more about this DAV implementation

mod_dav currently implements a Class 1 and Class 2 DAV server. This means that it provides all the basic DAV facilities for manipulating resources (files) on the target web server, along with manipulating properties on those resources. In addition, it handles the (un)locking of resources so that clients can have exclusive access to modify resources.

This is the final, 1.0 release. It is very stable and well-tested, after its nineteen month development period. Since there is no rush to market on an Open Source product, mod_dav was not labelled as 1.0 until it really felt like a 1.0 release.

Additional patches and releases will be created for mod_dav 1.0 as problems arise. For example, mod_dav 1.0.1 was released on June 28, 2000 to fix a problem on the Win32 platform. mod_dav 1.0.2 was released in October, 2000 to improve the configuration and build process, enhance the conformance to various specifications, fix a number of bugs, and provide for operation on EBCDIC machines.

mod_dav has been incorporated directly into the Apache server's next major release -- Apache 2.0. Development of new functionality and features will be focused on Apache's DAV implementation.

Note: it is entirely possible that some people will want to continue developing a version of mod_dav that works with the Apache 1.3 server. Information will appear here, if this happens.

The implementation is quite complete, except for a few variations from the spec, which I discuss below, along with other known problems. These problems will be fixed in future releases. Also see the Futures section for where mod_dav is headed.

The DAV server operates against the file system to fetch and store the DAV resources and collections (files and directories). Within each directory is a sub-directory named .DAV that contains SDBM (or GDBM) databases to hold properties for the directory itself and each file within the directory.

mod_dav's custom properties

mod_dav is built to provide for custom, live properties defined by plugin modules. The default filesystem plugin defines a single property for managing the "executable" permission flag on files. Setting this flag to true is similar to doing a chmod +x filename. This allows an author to upload a CGI script, then to mark it as executable by the operating system.

Name: executable Namespace: http://apache.org/dav/props/ Purpose: Describes the executable status of the resource. Value: "T" | "F"    (case is significant) Description: This property is defined by mod_dav's default repository, the "filesystem" repository. It corresponds to the "executable" permission flag in most filesystems. This property is not defined on collections.

Storage of dead properties

Hoo boy. If you want a hot issue, this is one. I asked a simple question about property values and caused a big discussion on the authoring list. Oops. In any case, it does mean that this is a hot topic, so I've called it out special.

mod_dav stores and returns dead properties in almost the same form as the XML that was provided in the PROPPATCH. Here are the specifics:

• All elements are retained, in order.
• All attributes are retained, possibly out of order.
• One exception to the above: xmlns attributes (namespace declarations) are removed from all elements within the property value. The namespaces are used, but the declarations get shifted "up" the element hierarchy.
• All element names and attribute names will be returned with namespace prefixes. These prefixes will invariably be different than the prefixes used (if any) during a PROPPATCH, although the related namespace URI is returned exactly as provided.
• Attributes on the property name element in a PROPPATCH are not considered to be part of the property value.
  (this is referring to attributes in the start tags of the child elements of <prop>)
• XML comments and processing instructions are removed.
• Whitespace in the text is preserved. Whitespace within the tags is not.
• xml:lang is preserved. It may be shifted "down" to a property name element from a higher scope in the PROPPATCH.
• Element and attribute names that use a (namespace) prefix beginning with "xml" will be preserved as-is (excluding xmlns:... and xml:lang). Namespace prefixes beginning with "xml" are reserved by the Namespaces in XML specification. Note that these prefixes may not actually have corresponding xmlns: declarations.

Here is an example of a PROPPATCH fragment and the resulting PROPFIND fragment:

  <prop>
  <x:myprop xmlns:x="http://host.domain.com/">
    <x:elem x:attr="value" />
  </x:myprop>
  </prop>

  <response xmlns:ns0="http://host.domain.com/">
  <propstat>
  <prop>
  <ns0:myprop>
    <ns0:elem ns0:attr="value"/>
  </ns0:myprop>
  </prop>
  </propstat>
  </response>

Note: I have avoided indentation of the elements to demonstrate the preservation of whitespace within the property value. The <status> and <href> elements have been omitted from the response for clarity.

Variations from RFC 2518

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.

The section numbers below refer to RFC 2518

• <DAV:propertybehavior> is not respected during a COPY or MOVE. In fact, the entire request body is ignored. Section 8.8.2 also states that live properties must be duplicated as dead properties at the target. In mod_dav's implementation, both sources and targets necessarily have the same set of live properties. It would be incorrect to turn a target's property from live to dead, so the RFC-required duplication does not occur.
• Locks do not record the authentication principal, nor do they enforce the same principal to be authenticated to use the lock. This contradicts section 6.3.
  this has been mostly fixed with the 1.0 release. some issues with POST need to be documented here.
• XML Namespace URIs and element names are treated as a tuple, rather than concatenated. Please see Yaron Goland's discussion of the issue. This contradicts the behavior specified in section 23.4.2.
• During a PROPPATCH, the <DAV:source> property is not checked for conformance to the DTD specified in section 13.10.
• DAV:getcontentlength is not defined for collection resources. This is contrary to the description in section 13.4.

Other implementation-specific details

These details are listed as the result of questions regarding the behavior of different DAV servers. As new questions and answers arise, I'll list them here. Note that these behaviors do not contradict RFC 2518; they are considered "implementation-specific."

• mod_dav responds with relativeURI values in the <DAV:href> element. The URIs are relative to the host. For example: <href>/some/path/somefile.html</href>. Some other servers return absolute URIs.
• In a PROPFIND response for a collection, mod_dav returns the collection properties after the properties of the collection members. Some DAV servers return the collection properties first.
• getlastmodified is based on the timestamp of the file containing the resource. Changes to properties will not update the getlastmodified property.
• getcontenttype and getcontentlanguage are readonly properties.
• mod_dav can return a 424 (Failed Dependency) in some situations (e.g. when lock validations fail). The body of the response contains a DAV:multistatus element with details about the resources which caused the failure.
• Lock-null resources do not respond to a GET. This means it is allowable for most of the standard DAV properties to not be defined. The following are not defined for lock-null resources: DAV:creationdate, DAV:getcontentlength, DAV:getetag, DAV:getlastmodified, DAV:displayname, DAV:source, and http://apache.org/dav/props/executable.

Futures

Now that mod_dav 1.0.0 has been released, I'll be concentrating on integrating mod_dav directly into the Apache 2.0 codebase. Additional features will be developed as part of Apache 2.0. I plan to add Versioning, Access Control, and then Bindings, References, and DASL (Searching).

Some people are looking at integrating mod_dav with PHP and for use in the Midgard Project. Rational Software has been experimenting with using mod_dav to access their ClearCase product.

Security issues

DAV allows users to place and manipulate files in a directory on your web server. This means that you should take particular care in configuring your DAV server.

When you enable DAV for a directory or location, you should also enable authentication and authorization for that space. If authorization (for authenticated users) is not enabled, then an anonymous user would have full control of the DAV-enabled portion of your web server.

Please see the installation instructions for information on how to properly configure your DAV server to prevent anonymous browsing and updating of your DAV-enabled web content.

At this time, the files that are managed within the DAV directory should be read/write for the web server process. Files and directories that are created by the DAV server will have read/write/exec privileges for the user and group (but not the world) of the server process and will be owned by the process' user/group. For example, if you run your web server as "nobody:nogroup", then you will want to create a base directory owned by nobody:nogroup and give it read/write/exec privs to the user and group.

Possible security attacks

Mostly, the DAV server is subject to Denial of Service attacks. These are listed below:

• If a user submits a PROPFIND, PROPPATCH, or LOCK request with a huge XML body, then the DAV server will parse that into memory. The process memory usage could grow and consume all available memory and swap space on your server.

  By default, mod_dav is compiled with a one million byte (100000) limit on the size of the XML request body. This limit may be changed by using the LimitXMLRequestBody configuration directive.

• A PROPFIND request with a Depth:&nbspInfinity header can cause mod_dav to walk the entire repository, building up a response (in memory) for the properties on each resource found. With a large repository, this can consume a lot of memory (the memory will be released when the request has been completed, but the peak can be troublesome).

  By default, mod_dav does not allow these kinds of requests. This behavior may be changed by using the DAVDepthInfinity directive.

• Users may submit large documents which would consume all available diskspace (on the disk partition or volume where the file ends up).

  Not much can be done on this one. Possibly some kind of user quota thing, but... eesh. For now, I'm going to say, "if they're authorized to PUT to the DAV server, then they should be responsible for how much data they store."

Known Problems

The mod_dav 1.0 release had no known bugs at the time of its release. If you find a problem, then please enter it into the mod_dav bug database.

Also, please see the install/configuration page if you are experiencing problems. A solution may exist there.

I'm also maintaining a page detailing significant, operational problems found in prior versions for people who haven't upgraded yet.

You've got patches to submit?

I'm absolutely interested in any patches that you may have. If you find and fix bugs, have platform-specific fixes, or you have patches for additional functionality, then please send them my way. I'll review and incorporate them, add your name to the list of acknowledgements, and release a new version.

A mailing list for users and developers is available at the dav-dev list information page.

Here is the current list of (code) contributors to mod_dav:

• Greg Stein
• Bill Bumgarner
• Ken Coar
• Rasmus Lerdorf
• Joe Orton
• Matthew Parry
• John Vasta
• Keith Wannamaker
• Peter Windle

I'd also like to thank all of the people who have provided bug reports, clarifications, interoperability experiences, etc. The number has simply grown to large to properly list them here. If you have ever dropped me an email with your issues, then you have my thanks!

I'd also like to thank Ken Coar for assistance in setting up mod_dav's anonymous CVS server.

Note: until requested, I won't add mailto: links in case people are leery of spam.

Licensing

The mod_dav software is licensed under an Apache-style license. A full copy of this license is available for reading, and is also enclosed with the software.

The goal for licensing this software is three-fold:

• To provide an Open Source DAV implemention to the user community.
• To enable Apache distributors and Apache developers (of derivative works) to include mod_dav in their distributions or software.
• To be flexible enough, such that commercial entities can work on and contribute to the Open Source version of mod_dav.

The choice of license to use was actually quite difficult because I would like to ensure that any changes that a commercial entity might make are delivered back to the community (a GPL or MPL style of license). Unfortunately, licenses along that line are hard to manage -- all of the existing, common licenses prevent commercial entities from working with the software (typically, due to patent issues), so a custom license would be required. The Apache-style or BSDish licenses typically don't have these restrictions, but they also don't require changes to be Open Source.

I am hoping that commercial entities using mod_dav will decide to contribute their changes back to the Open Source version. Personally, I believe it is in their best interest (primarily, because the community can debug/enhance/maintain the changes, rather than that companies in-house staff doing so, and dealing with remerging their changes with new versions of mod_dav).

I would like to publicly thank both IBM and Rational for following the spirit of mod_dav's Open Source development. Both companies have contributed extensive patches to mod_dav. IBM contributed the Class 2 locking facilities (by Keith Wannamaker), and Rational contributed the repository-independent subsystem hooks (by John Vasta). Thank you!

It is also interesting to note that Red Hat ships mod_dav as part of their E-Commerce Server.

Please contact me if you have any questions, or you are interested in including mod_dav in your Apache software.

Additional notes

Early versions of mod_dav (0.9.0 through 0.9.5) were licensed under the LGPL. I changed this to ensure that mod_dav reached the broadest audience possible.

Versions of mod_dav prior to 0.9.7 used GDBM to hold properties. The GDBM library is GPL'd, meaning that you cannot (by default) link against it without using the GPL yourself. Starting with 0.9.7, the properties are stored in SDBM databases, and GDBM has been relegated to an option. My understanding is that this satisfies GDBM's licensing.

DAV clients

Please see additional information on the Projects and Software page.

For my own testing, I've been using a couple Python scripts:

• davlib.py: this is a client-side module to interact with a DAV server.

  Note: davlib.py requires my HTTP/1.1 version of httplib.py and the qp_xml library. See my Python software page for more information.

• The mod_dav distribution includes the util/regress script, which runs several tests against an installed server. This test script is not particularly user-friendly, but will be very helpful for Python programmers.

Change History

• Version 1.0.3-1.3.6 (released 05-Nov-2001)

  • fix structure alignment problem which caused crashes in UNLOCK on some architectures (Jean-Frederic Clere, Dave Kristol)
  • ignore Depth: Infinity for non-collection resources in a PROPFIND; this prevents a bogus error when someone has not used the "DAVDepthInfinity On" directive
  • fix for Web Folders not recognizing the last-modified date in PROPFIND responses (Joe Orton)
  • tweak to also allow recognition of the creationdate
  • fix copying of collection properties during a Depth:0 operation (Keith Wannamaker)
  • return 507 (Insufficient Space) for quota errors (on Linux, at least) (Joe)
  • fix moving/copying of a collection over a non-collection (found by Joe's interop testing tool)
  • LOCK with a missing intermediate collection now returns a standard 409 (Conflict) response rather than 500 (Internal Server Error) (Keith, reported by Dan Brotsky)
  • Windows build updates for more recent Apache layouts (Keith)
  • fix problem with MOVE/COPY to a destination that is a locknull resource. (reported by Patrick Collins)
  • fix problems with empty URIs in xmlns attributes (fixes from Joe and Greg, reported by Julian Reschke)
  • removed generated files from CVS; added autogen.sh
  • build/config changes: look for shared Expat; AIX build tweaks (Joe, Matt Sergeant, Greg)
  • fix moving of a collection over a non-collection (reported by Joe's interop tool)

• Version 1.0.2-1.3.6 (released 19-Oct-2000)

  • ./configure and build updates:
    • allow building from outside the source directory (Fred Sanchez)
    • proactively detect broken APXS installations (idea from PHP)
  • updated INSTALL doc to document broken APXS installs and with more information about the Last-Modified header problem
  • minor changes to dav_dyn to make it easier for third parties to add backend modules
  • the DAV directive now takes a provider name (e.g. DAV svn). DAV On enables the default provider.
  • DAV Off is no longer allowed *under* a DAV On directive -- once a parent location/dir defines a DAV provider, then that provider handles everything under it.
    [ this is a possible backwards-compat issue for httpd.conf ]
  • add some slack time for expiring locks: we report an expriation of N seconds, but the timeout doesn't occur until N + 120 seconds. this helps out Office which sends its Refresh too close to the expiration time, and can then miss due to latency
  • fix handling of the If-Unmodified-Since header by updating the request_rec's mtime field. (Joe Orton)
  • partial fix for filesystems that can have file sizes more than 4G. small files are reported properly; large files could still be reported incorrectly. (Annette DeSchon)
  • maintain the executable property across COPY and MOVE (Joe Orton)
  • update opaquelock functionality and Expat parsing for proper operation in EBCDIC environments (Jean-Frederic Clere)
  • fix leak of subrequests in property handling (Joe Orton)
  • put real status text into our Multistatus responses
  • fix for operation in an IPv6-enabled Apache (Rolf Haberrecker)
  • if a lock fails due to authentication problems, return a 403 (Forbidden) rather than 401 (Unauthorized). this fixes an HTTP conformance issue where we returned 401 but no WWW-Authenticate response header. (Joe Orton)
  • return 413 (Request Entity Too Large) when the XML request body exceeds the limit, rather than 400 (Bad Request). (Joe Orton)
  • fix byterange handling for custom repositories (Joe Orton)
  • fix lock inheritance on the destination of a COPY/MOVE (Joe Orton)

• Version 1.0.1-1.3.6 (released 28-Jun-2000)

  • fix binary file corruption on Win32 (from Barry Pederson)
  • small tweak in dav_fs_repos.c to aid AIX compilation (via xlc)

• Version 1.0.0-1.3.6 (released 13-Jun-2000)

  • new directives:
    • DAVDepthInfinity (from Joe Orton) to control whether PROPFIND with a Depth: infinity is allowed.
    • LimitXMLRequestBody to control the size of XML request bodies (for PROPFIND, PROPPATCH, LOCK)
  • implement Content-Range support for the GET and PUT methods
  • locks record the authenticated principal (from Keith Wannamaker)
  • fix errors in dav_dyn which prevented proper operation when mod_dav is statically linked.
  • fix another tweaky error related to startup initialization which ended up causing MOVE/COPY to non-DAV directories to act funny
  • filenames are now case-preserved on a PUT (from Keith Wannamaker)
  • fix bug with timing-out indirect locks
  • Win32 no longer defines the "executable" property
  • fix up error handling in MOVE/COPY/DELETE
  • fixes for "insufficient storage" errors (from Joe Orton)
  • fix UNLOCK for locknull resources
  • disable writing to DAV:getcontenttype and DAV:getcontentlanguage (to be fixed in a future version)
  • update prop handling to deal with multiple liveprop providers
  • delay creation of the propdb until a dead prop is truly stored. this prevents the creation of a propdb when the client is merely setting the "executable" flag.
  • fix crasher when validating the root of a DAV tree (from Joe)
  • properly deal with HEAD requests when we have a custom repository
  • internal cleanups: lint, error propagation, depend on dav_error logging rather than direct logging

Please see the CHANGES file in the distribution for the changes to earlier versions.