httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: mod_mime.c#find_ct() redux (Re: automatic type identification (by extension) in virtual DAV repositories)
Date Thu, 05 Jun 2003 07:26:33 GMT
--On Wednesday, June 4, 2003 11:33 AM -0700 Chris Knight 
<Christopher.D.Knight@nasa.gov> wrote:

> 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 
test-dev@httpd.apache.org.  -- justin

Mime
View raw message