I believe this should be reflected in the documentation. Because after
reading Eagle book one gets absolutely different understanding. It
doesn't diffirentiate Perl stacked handlers and Apache handlers. From
Doug's words (and from practice :) those are slightly different in the
way how their return codes are treated.
BTW. Do I understand it correctly now that if my PERL handler returns
either OK or DECLINED then the next PERL handler (if
any) for this phase will be called anyway, but Apache "native" handlers
will be called depending on what is the phase. Ie. for URL translation the
"native" handler will be called only if last Perl handler returned DECLINED.
Andrei
On Tue, Dec 21, 1999 at 01:45:40PM -0800, Doug MacEachern wrote:
> > At least that's what I thought !
> >
> > In fact now Apache lets me use more then one
> > PerlTransHandler, but it doesn't care
> > of what is the return codes are!!!
> >
> > Even I return OK, it still calls
> > next registered handlers. Really weird!
>
> mod_perl does care. but, mod_perl stacked handlers are not quite the same
> as Apache C handlers. unless the return status from a Perl handler is
> something other than OK or DECLINED, mod_perl propagates the status code
> of the last handler run back up to Apache.
> originally, stacked handlers were introduced for chaining multiple content
> handlers. if the OK status from the first handler was propagated back to
> Apache, there would be no chain, and little use for stacked handlers.
>
> you can always override this behavior by using a single Perl*Handler which
> decides what path to take based on the return status, or use a
> PerlDispatchHandler, or PerlDirectiveHandlers, to name a few.
>
>
--
