First, apologies for being dense with regards to ModMimeUsePathInfo, the issue regarding Content-Type auto-identification has nothing to do with this directive.
Um, that is exactly what ModMimeUsePathInfo does. But, let me clarify a few things: this is only on the Content-Type sent in the response headers - not for the request (i.e. on a PUT without a Content-Type) - and this isn't mod_mime_magic which looks at the content to determine the content-type.
mod_dav_fs is a special case because it goes down to the file level rather than being at the virtual location layer (r->filename is correct on its own). So, it doesn't need ModMimeUsePathInfo.
ModMimeUsePathInfo doesn't work with mod_dav_svn right now, but that's because mod_dav_svn unconditionally internally sets the MIME content-type (and uses the wrong API to boot). Although I should probably fix that, but that's neither here nor there for this list.
It looks like Catacomb (0.8.0 is what I just downloaded) is doing the same thing in its dav_repos_set_headers as mod_dav_svn. That hook runs after the fixups hooks, so it just trounces on the content-type that mod_mime tried to set with ModMimeUsePathInfo.
In doing some debugging, with mod_dav_fs (with DEBUG_GET_HANDLER defined in repos.c) I've found that find_ct is not called to identify the type. I'm
Well, here, find_ct is called in the fixups stage. So, I'm not sure what's going on for you. Some more specifics could be helpful.
assuming the inability to run PHP scripts from a DAV server is the same problem. Bug or feature?
Note that since PHP 4.2.3, which (I believe) introduced the PHP handler for httpd-2.0 and removed the PHP filter, it's not possible to do this chaining. Implementing PHP as a filter got to be a nightmare, and we eventually gave up and did it as a handler instead. One of the drawbacks is that PHP can't work off of virtual repositories or anything that has its own handler now.
(PHP requires file-backed input into its parser which kills it for Subversion and httpd-2.0. I believe there may be some work to allow PHP to take in push-based streams like Apache httpd output filters can deliver - when that is ready, we can reexamine PHP as filter again and determine what needs to happen on httpd's side to make it all happy - there is definitely some work that has to be done to httpd as well.)
Also, I would highly recommend that testing of Apache include testing the GET handler in mod_dav_fs. There are other backends (Catacomb, ?) that use mod_dav as their front-end and who handle GETs themselves and we're running into these issues.
httpd-test's perl-framework already has some tests for WebDAV that does exactly this. Feel free to help us expand our tests over on [EMAIL PROTECTED] -- justin
