This page details some significant problems that were fixed in each release of mod_dav. The main mod_dav page only lists summaries of the changes in each version.
This information is provided to aid people who are still running these older versions. These issues will most likely interfere with the proper/secure operation of their DAV server.
No interoperability or security problems were fixed in the 0.9.12 release.
In certain cases, Apache would set a pointer to NULL and mod_dav was not prepare for it -- crashing the server.
DAV:getcontenttype and DAV:getcontentlanguage were implemented in 0.9.11. However, they are picked up from a PROPPATCH or running an Apache "sub-request." They are not (yet) stored from the headers of a PUT request.
If-* headers are now processed
The introduction of locking (Class 2 functionality) in 0.9.9 means that mod_dav can now interoperate with Microsoft's Office 2000.
The xmlns="" handling was incorrect.
PROPPATCH did not generate error responses properly.
IE5 does not use fully-qualified hostnames in the
Destination: header which could cause problems
with MOVE and COPY. A workaround was added.
If a problem occurred during a PUT, then the input stream was not properly flushed, causing Apache to attempt to process the tail-end of a PUT request.
If: header processing was not implemented at all.
The Destination of a MOVE/COPY is not authorized. 0.9.7 includes some code which should fix this.
Up until this version, xml:lang values were handled improperly or not at all.
MOVE/COPY across devices had some issues.
Prior versions trapped the POST request, rather than ignoring it. Now, mod_dav does not alter the "handler", which allows the POST to be processed normally.
The Makefile.apxs that is shipped with mod_dav uses a feature only found in Apache 1.3.4. Notably: the -Wc,-Wall command line option, which passes -Wall to the compilation step. As of 0.9.6, you must use 1.3.4, so this incompatibility with previous Apache versions is no longer relevant.
Prior versions did not handle any element or attribute that had a prefix that started with "xml". The XML Specification states that these are reserved, which means they might be used at any point in the future. mod_dav now passes these through unchanged rather than returning an error for an "unrecognized prefix".
In particular, prior versions would blow up on the xml:lang attribute for this reason (in addition to other xml... prefixes).
DELETE on an empty collection fails, starting with 0.9.2.
MKCOL with a trailing slash on the URI fails. Similarly, COPY or MOVE with a trailing slash on the Destination fails.
A behavioral change in error processing from Apache 1.3.2 to 1.3.3 introduced incorrect response bodies for HTTP_CREATED (201) and other responses. While harmless, it was incorrect behavior.
In certain cases, if a PROPFIND is performed with a <prop> style query, and the only properties requested are DAV: properties, then the response will not contain the successful results. Instead, it will only report those that could not be found.
A COPY or MOVE with an improper destination should return 502 (Bad Gateway) rather than 400 (Bad Request). There are certain cases where the latter makes sense, but it is applied too broadly.
A COPY or MOVE of a source URI "up" to a destination that contains the source is not trapped. It should return a 403 (Forbidden).
There was a stupid bug in the Overwrite header handling, where it wouldn't properly deal with a "T" value. Just omit the header, if possible, since "T" is the default.
A PROPFIND "prop" request for DAV:resourcetype will crash the server.
PROPFIND (and possibly other requests) for a collection URI with a trailing "/" may return <href> elements (in a <response> element) that contain double-slashes. For example, given a URI of "/dav/", you could get back "/dav//index.html".
0.9.2 fixed the PROPFIND (and the shared code may also help MOVE, COPY, and DELETE), but testing has not been performed yet to check URI manipulations of those other methods.
A PROPFIND "prop" request would sometimes return an invalid property name in the response when the resource (collection or member) did not have the property. Specifically, if there were no dead properties or none of the other dead properties had the same namespace as the requested property.
On a PROPFIND, the DAV properties won't be found or returned if there are no dead properties on the file.
mod_dav effectively does a SetHandler on the directory that is configured. This is disabling other modules such as mod_mime and mod_dir, so standard HTTP GET requests are not operating "right".
Note that the Expat distribution's Makefile won't create a libexpat.a by default. Just add a target in there to "ar" all the .o files (or do it by hand). Rasmus Lerdorf has sent me some good material which be placed into a INSTALL file for the 0.9.1 release (dealing with Expat and Apache config).