Stacked handlers in Apache2 with Plack?

47 views
Skip to first unread message

thijso

unread,
Apr 15, 2013, 5:53:25 AM4/15/13
to psgi-...@googlegroups.com
Hi,

I am in the process of finally updating a legacy app from Catalyst 5.8xxx to 5.9xxx and with that update comes Plack.

Our app more or less depends on the stacked handlers you can use in Apache: define multiple handlers and in each handler return a value indicating if the request is done or should be passed on to the next handler in line.

One option is to migrate all these handlers into the Catalyst dispatching structure, which is possible, but a lot of work. So I was wondering if it is possible to have Plack act the same and just return a DECLINED or OK depending on whether to continue down the line or not? Or is there some other mechanism I can use? Build a specific middleware, maybe? If so, any pointers on how that would look?

Thanks,
thijso

Aristotle Pagaltzis

unread,
Apr 15, 2013, 7:14:56 AM4/15/13
to psgi-...@googlegroups.com
* thijso <thi...@gmail.com> [2013-04-15 11:55]:
> So I was wondering if it is possible to have Plack act the same and
> just return a DECLINED or OK depending on whether to continue down the
> line or not? Or is there some other mechanism I can use? Build
> a specific middleware, maybe? If so, any pointers on how that would
> look?

Are you looking for Plack::App::Cascade?

If not, then your app is probably relying too intimately on Apache to be
able to divorce it without the significant overhaul you are fearing. But
it’s hard to say anything definitive about it with as little information
as you have given.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

thijso

unread,
Apr 15, 2013, 7:25:50 AM4/15/13
to psgi-...@googlegroups.com
Plack::App::Cascade looks nearly like what I'm after.

Apache2 stacked handlers work with Apache2 constants as return values to indicate what apache should do next. For example, if I return DECLINED, apache will try the next handler in the list. If I return DONE, apache will stop in the list and pass on what I printed to apache as the response.

Plack::App::Cascade works with HTTP return codes, and will try the next while the return is a 404.

Maybe I could look at the internals and adapt it to my situation, though.

Ævar Arnfjörð Bjarmason

unread,
Apr 15, 2013, 10:19:14 AM4/15/13
to psgi-...@googlegroups.com
On Mon, Apr 15, 2013 at 1:25 PM, thijso <thi...@gmail.com> wrote:
> Plack::App::Cascade looks nearly like what I'm after.
>
> Apache2 stacked handlers work with Apache2 constants as return values to
> indicate what apache should do next. For example, if I return DECLINED,
> apache will try the next handler in the list. If I return DONE, apache will
> stop in the list and pass on what I printed to apache as the response.
>
> Plack::App::Cascade works with HTTP return codes, and will try the next
> while the return is a 404.
>
> Maybe I could look at the internals and adapt it to my situation, though.

I did a similar conversion to Plack from mod_perl, could you please
paste your whole Apache config to the list?

Depending on what Apache features you're implicitly relying on under
mod_perl you may have to do some very different tricks in Plack-land
to emulate them, or not.

E.g. I have a ~300 line function that handles the emulation of stacked
handlers & cleanup handlers along with ErrorDocument directives.

Also note that you can change over to the "unstacked" handler *before*
you migrate to Plack. That's what I did. It makes it much easier to
determine if that code is buggy, or whether something else in your new
setup is buggy.

thijso

unread,
Apr 15, 2013, 11:15:11 AM4/15/13
to psgi-...@googlegroups.com
Basically the relevant config was this:

SetHandler              perl-script
PerlHandler             XXX::ApacheHandler::Ratelimit       XXX::ApacheHandler::Redirect   Foo     XXXSite::Dispatcher

Foo is the 'new' Catalyst app. In the old situation (pre 5.9xxx for Catalyst, without Plack) we could do $c->engine->return( DONE() ) or DECLINED() (or some other Apache constant).

For example, in case of a returned DECLINED(), Apache would continue in the XXXSite::Dispatcher handler. In case of OK or DONE, it would just return what it got and skip the handlers that follow.

Looking a bit more at Plack it seems this is too much tied to Apache(2). So I think I'll bite the bullet and rewrite the custom dispatchers into catalyst actions. More work, but cleaner in the end, probably.

Aristotle Pagaltzis

unread,
Apr 15, 2013, 12:29:13 PM4/15/13
to psgi-...@googlegroups.com
* thijso <thi...@gmail.com> [2013-04-15 17:20]:
> Basically the relevant config was this:
>
> SetHandler perl-script
> PerlHandler XXX::ApacheHandler::Ratelimit
> XXX::ApacheHandler::Redirect Foo XXXSite::Dispatcher
>
> Foo is the 'new' Catalyst app. In the old situation (pre 5.9xxx for
> Catalyst, without Plack) we could do $c->engine->return( DONE() ) or
> DECLINED() (or some other Apache constant).
>
> For example, in case of a returned DECLINED(), Apache would continue
> in the XXXSite::Dispatcher handler. In case of OK or DONE, it would
> just return what it got and skip the handlers that follow.
>
> Looking a bit more at Plack it seems this is too much tied to
> Apache(2). So I think I'll bite the bullet and rewrite the custom
> dispatchers into catalyst actions. More work, but cleaner in the end,
> probably.

Sounds like you were using Apache handlers as the equivalent of
middlewares in a PSGI stack, e.g. Plack::Middleware::Throttle.
Reply all
Reply to author
Forward
0 new messages