Upgrading chained response handlers to mod_perl2

Hi,

I'm in the process of upgrading an application to mod_perl2. The
application currently relies on chained content handlers. Each
PerlResponseHandler in the chain uses the following mechanism to get
(and then process) the requested file:

$r->filter_register;
my ($fh, $status) = $self->{'r'}->filter_input();
....
....

The call to ->filter_input takes care of whether to open the file from
disk or read it from the previous response handler in the chain, so that
each response handler in turn can make changes to the

Reading through the mod_perl2 docs, it's clear that the new
Apache2::Filter mechanism is far more powerful and flexible, but I'm not
currently in a position to re-engineer the application to change it from
a response handler to a PerlOutputFilterHandler.

In my imagined upgrade path there would be a way to replace the
->filter_input call with some calls to the new Apache2::Filter API to
slurp the data into the handler. Perhaps I'm missing something glaringly
obvious, or simply trying to bang a square peg in a round hole.

And pointers on this would be greatly appreciated.

Regards,

Iain

Re: Upgrading chained response handlers to mod_perl2

Hi,

Is there a data structure that gets passed to each response handler in
the chain that the processed file can be stored in (like $f->ctx)?

Can the old mod_perl1 ->filter_input behaviour be done by manipulating
the input_filter or output_filter stacks?

Is what I'm trying to do vaguely sane, even? With the following directive:

PerlResponseHandler +Module::Test1 +Module::Test2

Having both Test1 and Test2 process the HTML response body in turn with
mod_perl1 was pretty straightforward. I reckon I must be missing
something pretty obvious, surely?

Iain

Iain Kennedy wrote:
> Hi,
>
> I'm in the process of upgrading an application to mod_perl2. The
> application currently relies on chained content handlers. Each
> PerlResponseHandler in the chain uses the following mechanism to get
> (and then process) the requested file:
>
> $r->filter_register;
> my ($fh, $status) = $self->{'r'}->filter_input();
> ...
> ...
>
> The call to ->filter_input takes care of whether to open the file from
> disk or read it from the previous response handler in the chain, so that
> each response handler in turn can make changes to the
>
> Reading through the mod_perl2 docs, it's clear that the new
> Apache2::Filter mechanism is far more powerful and flexible, but I'm not
> currently in a position to re-engineer the application to change it from
> a response handler to a PerlOutputFilterHandler.
>
> In my imagined upgrade path there would be a way to replace the
> ->filter_input call with some calls to the new Apache2::Filter API to
> slurp the data into the handler. Perhaps I'm missing something glaringly
> obvious, or simply trying to bang a square peg in a round hole.
>
> And pointers on this would be greatly appreciated.
>
> Regards,
>
> Iain
>

Re: Upgrading chained response handlers to mod_perl2

Iain Kennedy wrote:
> Hi,
>
> Is there a data structure that gets passed to each response handler in
> the chain that the processed file can be stored in (like $f->ctx)?
>
> Can the old mod_perl1 ->filter_input behaviour be done by manipulating
> the input_filter or output_filter stacks?
>
> Is what I'm trying to do vaguely sane, even? With the following directive:
>
> PerlResponseHandler +Module::Test1 +Module::Test2

I'm not sure, but i don't think you can really do that in mp2, i think
you need to read about how filters work in mp2, then do something like

PerlResponseHandler Module::Test1
PerlOutputFilter Module::Test2

where Module::Test2 has been rewritten using the filter API. Geoff
Young gave a talk about filters at an apachecon many moons ago that i
found particularly helpful, you can still find the slides here:

http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2006/ mp2_filters-printable.pdf.gz


> Having both Test1 and Test2 process the HTML response body in turn with
> mod_perl1 was pretty straightforward. I reckon I must be missing
> something pretty obvious, surely?
>
> Iain

HTH,

Adam