Login | Register
My pages Projects Community openCollabNet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Catacomb] fixed -- mod_mime.c#find_ct() redux



Justin Erenkrantz wrote:

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.

Ah, good call. I've fixed Catacomb to not do this anymore unless the RDBMS has Content-Type defined.

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.

I think because content_type was already defined, it skipped calling ap_run_type_checker?

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.)

This is a major issue with non-fs backends...One option would be to re-do the filter to use a temporary file to feed to PHP (a gross hack, I know.) Thanks for the details/history...

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

Strangely, I am not seeing the problem with mod_dav_fs anymore...Perhaps I was hallucinating...I guess it "works for me". :^o

Good news is I now have a much firmer grasp of the internal workings of Apache...

Is there an active project to write/improve the documentation of these internal workings?