Ken Williams wrote:
> Changes:
>
> - Added 'handle' parameter to filter_input(), which lets callers open the
> input filehandle themselves.
> [[EMAIL PROTECTED] (Vegard Vesterheim)]
Hi Ken.
I've figured out that using this, I can *cheat* and get Apache::Filter
to
work with my handler whereas I could not get it to work before. Let me
explain.
I've got a PerlHandler called "MJS::AppServer" which was configured as:
<Location /myapps/>
SetHandler perl-script
PerlHandler MJS::AppServer
</Location>
Basically what this handler does is accept a URI like:
/myapps/CreateUser
and the handler sees that "CreateUser" is in the path info. Because of
this,
it does "my $app = MJS::Applications::CreateUser->new($r);
$app->service();"
(well it does more, but that is the basic thing it does).
Anyway, when using previous versions of Apache::Filter with this
handler, I
would get "NOT_FOUND" returned because of course, Apache::Filter cant
open
/myapps/CreateUser.. it just plain does not exist... Neither does the
directory /myapps.
But, using this version, in AppServer.pm, I am able to do:
if (lc $r->dir_config('Filter') eq 'on') {
$r->filter_input(handle=>1);
}
And everything is fine from then out (I usually pass it through
Apache::SSI).
So now we use it like:
PerlHandler MJS::AppServer Apache::SSI
And it all works.
Maybe you could consider making a dir_config() directive to
get this behaviour? Something like "Filter_No_Input On" to say
that there is no input for the first handler and the first handler
provides the output itself? That way I dont have to resort to
abusing the "handle" argument to get the desired behavior :)
Or is there a different way to do this that I am missing?
Thanks.
Mike Schout
