perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Quatravaux <>
Subject Re: mod_perl2 and PHP
Date Mon, 08 Aug 2005 08:56:14 GMT
Hash: SHA1

Thomas Klausner wrote:

> Hi!
> Is it possible and advisable to write the complex part of an
> application (the Controller, if you like) in mod_perl2 and use PHP
> as a frontend (or View) ?

It definitely is, we did just that in my shop: there is some code at (have a look at
idxpki-v1.9.0/src/perllib/IDX/PKI/ inside the tarball).

> While I personally prefere Template::Toolkit as a presentation
> language, the project I'm currently getting involved in has quite a
> lot of PHP-people and not that many (read: me) Perl people.

Pretty much the same rationale over here. It turned out to be a winner
for hitting a release quickly, but it does have drawbacks e.g. over
time I've been forced to write some view code and I *hate* PHP :-].
Also don't expect PHP to give you a hand for standards compliance
(e.g. making sure that all your Web pages are valid XHTML).

> But: can I create a datastructure in Perl (in an ResponseHandler)
> and pass it on to PHP running also as an ResponseHandler, but
> afterwards.

Yes. You can pass small amounts of data by messing with the GET
parameters (not POST, see below) using $r->, and large amounts of data
through $r->subprocess_env() (undocumented but present in mod_perl
1.3, and see Apache2::SubProcess for 2.0).

Then, in order to transfer control to PHP, you have to trick it into
thinking it's serving a PHP subrequest (for what it has built-in
support). You have force the method of the request to GET (lest PHP
tries to fetch the POST body again, and fail), and then invoke
$r->internal_redirect() (again undocumented but present in mod_perl
1.3, and see Apache2::SubRequest for 2.0).

There is some jockeying around with the variable names to correctly
get data across the PHP boundary: if you do $r->subprocess_env("FOO",
$value) from Perl, then you can retrieve $value from PHP by requesting
$_SERVER["REDIRECT_FOO"] (the REDIRECT_ part is added by the internal
redirection mechanism).

Sample code for all of this lies in
idxpki-v1.9.0/src/perllib/IDX/PKI/, around lines 1648
(internal redirect) and 976 (subprocess_env).

> Would I need to stuff data in ENV?

This is a third channel available (in addition to GET parameters and
the subprocess_env), but I would *not* recommend using it. The UNIX
environment has all sorts of bad properties for passing data around
inside a single process (see my rant at
In my case, we had issues of %ENV not being properly reset between
requests, which caused request data to "leak" from one page to another
in a nondeterministic fashion (due to there being multiple Apache
processes). Long story short - it caused a superb train wreck in
production. We could probably have dealt with the mess using a cleanup
handler, but relying exclusively on data structures that are
guaranteed to be destroyed at the end of the request is a much cleaner
solution IMHO.

> Can I pass complex data structures around? Do I have to serialise
> (to yaml/xml) between Perl and PHP?

YAML is a good move, I would probably go for it if I had to redo my
stuff. We used a recursive phpencode() function (look for it in, which is a close cousin do Data::Dumper::Dumper(), but
returns a string that can be eval'd in PHP. This is quite easily done,
and works fine provided you make *really really sure* that eval'able
code only comes to PHP through a trusted channel, that is,
$_SERVER["REDIRECT_FOO"] for well-known values of FOO *ONLY*. Don't
eval stuff from the GET cmdline!

- --
Dominique QUATRAVAUX                           Ingénieur senior
01 44 42 00 08                                 IDEALX

Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


View raw message