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