> I do now - just uploaded a new version. It's still not correct though - a
> proper fix would have to pull SetHandler out of mod_mime altogether, I
you'd still have the same problem, Apache stops calling type handlers
after the first one returns OK. besides, you can apply the SetHandler
config in your TypeHandler by using a subrequest, no need to pull it out
of mod_mime.
> I guess one important question is - why do we have to call SetHandler for
> PerlHandlers and not for any of the other handler phases. For all the
> other phases Apache/mod_perl automatically figures out if there's a
> handler installed and either runs perl code, or lets apache do its
> work. Why can't PerlHandler do the same? (as you can tell - I haven't dug
> into the internals of this - but I am curious).
because Apache dispatches response handlers based on the modules'
handler_rec (part of the module structure). the key Apache uses to do
that lookup is r->handler, which if NULL, falls back to r->content_type.
> Right. So what's the point of PerlTypeHandler again?... ;-) Seriously
> though - Apache::MimeXML is the only PerlTypeHandler, as far as a quick
> search reveals, apart from your examples in the book. So maybe it would be
> worth investigating this further.
there's nothing to investigate, Apache is working as it is designed.
if you feel this is a design flaw, the the issue should be raise on
[EMAIL PROTECTED] list.
as i mentioned above, alternative to the FixupHandler workaround, if your
TypeHandler wants to let mod_mime contribute, it can run a subrequest and
copy the $subr->{handler,content_type} as you see fit.
> A fixup handler is an interesting solution... but can I stack
> FixupHandlers? (I run most of my mod_perl code from a FixupHandler).
yes.
> Also, you didn't pick up on something I sent to the list in another
> thread... I have code that goes:
>
> if ($r->current_callback eq 'PerlFixupHandler') {
> $r->push_handlers('PerlHandler', \&code);
> }
> else {
> &code($r);
> }
>
> so that I can install the module as either a fixup or a PerlHandler. The
> fixup installed version is 4 times slower than calling the function
> directly - is that to be expected? (we're talking 20 requests/sec vs 80
> here - a huge difference).
i wouldn't expect that much of a difference. i'll look into it.
