Frank Wiles wrote:
On Tue, 11 Jan 2005 14:02:00 -0500 Jim Albert <[EMAIL PROTECTED]> wrote:
Under mod_perl1 I had a mod_perled program that opened a pipe to a standard CGI and recorded its output.
I did this in my mod_perl program by setting the following ENV vars: $ENV{"QUERY_STRING"} $ENV{"REQUEST_METHOD"} $ENV{"CONTENT_LENGTH"}
and then opening a pipe to the CGI.
The problem under mod_perl2 that I now see is that my standard CGI is not getting the QUERY_STRING information.
I see at
http://perl.apache.org/docs/2.0/user/porting/compat.html#Issues_with_Environment_Variables
the following information:
"Forked processes (including backticks) won't see CGI emulation environment variables. (META: This will hopefully be resolved in the future, it's documented in modperl_env.c:modperl_env_magic_set_all.)"
Does anyone have any information as to whether this issue will be resolved in mod_perl2?
If not or not anytime soon... can someone suggest a way for my mod_perl2 script to open a pipe to a standard CGI that relies on QUERY_STRING for its input?
I was thinking of having my mod_perl2 script open a pipe to a perl script that will take some query_string and such as parameters. That intermediate script could set the appropriate environment variables
and open a pipe to my standard CGI. That might work, but it seems
messy.
This may not work, but I've seen people pass environment variables
on the commandline before... like so:
# TEST=foobar ./test.pl
This sets $ENV{TEST} == 'foobar'. Not an elegant way to work around
it, but it should then be passed to the CGI.
More or less, that's what I did. I have my mod_perl script open a pipe and pass the query string and other information to a regular perl script (call it 'middleman') as command line parameters. middleman then sets the ENV and opens a pipe to the CGI.
It works, but I don't really like the solution. Luckily, this is not something that runs a whole lot, so the additional time and resources are not a big deal.
-- Jim Albert
