Mowser
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 gstein@lyra.org.
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.
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.
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:
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 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:
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.
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 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.
executablehttp://apache.org/dav/props/T" | "F" (case is significant)This property is not defined on collections.
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:
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.<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.
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.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.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."
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.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.
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.
Mostly, the DAV server is subject to Denial of Service attacks. These are listed below:
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.
PROPFIND request with a Depth: Infinity 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.
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."
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.
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:
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.
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:
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.
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.
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 theutil/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.Version 1.0.3-1.3.6 (released 05-Nov-2001)
Version 1.0.2-1.3.6 (released 19-Oct-2000)
Version 1.0.1-1.3.6 (released 28-Jun-2000)
Version 1.0.0-1.3.6 (released 13-Jun-2000)
Please see the CHANGES file in the distribution for the changes to earlier versions.
You are viewing a mobilized version of this site...
View original page here
Mowser