Apache1 MOD_PERL variable

[Abelard]

Hi.

In Plack::Handler::Apache1::load_app, the MOD_PERL environment variable is deleted prior to loading the app. A comment says:

" Trick Catalyst, CGI.pm, CGI::Cookie and others that check for $ENV{MOD_PERL}."

This appears to only be done on the initial load, however. During a request, MOD_PERL is defined.

It seems like it should be one or the other, no?. Either always fake us out and not let us know we're running under mod_perl, or don't.

I have an old mod_perl app I'm updating to work with Plack, and this behavior is confusing it; during initial preload, it's installing some mock objects in order to run outside the mod_perl context. But during runtime, there are other checks for MOD_PERL that are passing.

[Tatsuhiko Miyagawa]

Yeah, I think it should unset the variable in the runtime as well, but I wonder to what extent it could break existing apps one way or the other. It might be worth a try anyway.

--
 
 
 

[Abelard]

On Friday, November 23, 2012 12:55:25 PM UTC-8, Tatsuhiko Miyagawa wrote:

Yeah, I think it should unset the variable in the runtime as well, but I wonder to what extent it could break existing apps one way or the other. It might be worth a try anyway

What was the original intent? To make sure the app could run outside the mod_perl environment?

What if it was a configurable option? 

[Tatsuhiko Miyagawa]

Original intent of what?

The reason to undo MOD_PERL environment on the compile time to avoid the load time optimization done by CGI.pm and other apps, so that they can work safely in the PSGI environment. There was no special reason to keep that variables around back in the request time, but I wouldn't be surprised if some apps depending to figure out MOD_PERL environment to do something special even with PSGI, but IMO these apps are bound to be broken anyway.

--
 
 
 

--
Tatsuhiko Miyagawa

[Abelard]

On Tuesday, November 27, 2012 3:49:31 PM UTC-8, Tatsuhiko Miyagawa wrote:

Original intent of what?

The reason to undo MOD_PERL environment on the compile time to avoid the load time optimization done by CGI.pm and other apps, so that they can work safely in the PSGI environment. There was no special reason to keep that variables around back in the request time, but I wouldn't be surprised if some apps depending to figure out MOD_PERL environment to do something special even with PSGI, but IMO these apps are bound to be broken anyway.

Yes. So a configurable option to undo MOD_PERL would be considered? Defaulting to undo?

[Tatsuhiko Miyagawa]

In the original reply i suggested it would make sense to remove MOD_PERL altogether for runtime as well. Why a configurable options? If you need one you should be able to set it anytime before your app starts, like in a piece of middleware.

--
 
 
 

--
Tatsuhiko Miyagawa

[Tatsuhiko Miyagawa]

I suggest you to open an issue on github issue tracker (https://github.com/plack/Plack) or even better, fork the code and submit a pull request.

--
Tatsuhiko Miyagawa

[Abelard]

On Wednesday, November 28, 2012 10:51:02 AM UTC-8, Tatsuhiko Miyagawa wrote:

I suggest you to open an issue on github issue tracker (https://github.com/plack/Plack) or even better, fork the code and submit a pull request.

Ok, will do. Thanks.

[Ævar Arnfjörð Bjarmason]

What were the checks for MOD_PERL during runtime that you initially
encountered this with? Something on CPAN or something in your own
code?

I run a fairly sizable codebase under the Apache2 handler and I
haven't encountered this.

> --
>
>
>

[Abelard Hoffman]

On Thu, Nov 29, 2012 at 9:45 AM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote:

What were the checks for MOD_PERL during runtime that you initially
encountered this with? Something on CPAN or something in your own
code?

I run a fairly sizable codebase under the Apache2 handler and I
haven't encountered this.

Hi.

It's our own code. On startup, we check whether MOD_PERL is defined, and if not, load some alternative/mock code. During runtime, some code is using those mock interfaces that was never expected to and blowing up.

We need to eventually remove those mod_perl dependencies anyway, of course. I was just surprised and it took a while to figure out what was happening.

-A

 

On Wed, Nov 28, 2012 at 11:58 PM, Abelard <abelard...@gmail.com> wrote:
>
>
> On Wednesday, November 28, 2012 10:51:02 AM UTC-8, Tatsuhiko Miyagawa wrote:
>>
>> I suggest you to open an issue on github issue tracker
>> (https://github.com/plack/Plack) or even better, fork the code and submit a
>> pull request.
>
>
> Ok, will do. Thanks.
>
> --
>
>
>

--