You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Chris Knight <Ch...@nasa.gov> on 2003/06/05 19:21:22 UTC

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?


Re: fixed -- mod_mime.c#find_ct() redux

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, June 5, 2003 10:21 AM -0700 Chris Knight 
<Ch...@nasa.gov> wrote:

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

I'm fairly sure it is run all the time, but I'd have to look to be sure.

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

And, that's an option that was suggested and discarded.  =)

> 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?

Just submit patches to dev@httpd.  There's some stuff in 
docs/manual/developer/ that might be a good starting point.  -- justin