perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2.0] Win32 ENV still not compatible with mod_cgi
Date Thu, 08 May 2003 04:17:35 GMT wrote:
> 1. Problem Description:
>  %ENV still not compatible with mod_cgi regarding mixed case variable names.
>  I had previously reported this problem with mod_perl-1.99_08 and I was
> delighted to find an update in
>  mod_perl-1.99_09 regarding Win32 env. However, the fix does not address the
> problem.

It addresses the first problem with PassEnv, on which you said it worked fine. 
You haven't followed up on my further questions, so the other things weren't 

> The following diff shows what I've done in my local version to make it
> compatible. I know that it probably
> does not address the root cause, but it fixes the key name at the lowest
> possible level to:-
> a) Ensure that the first character of the name is not a digit (re mod_cgi)
> b) All non alpha-numeric characters are replaced with '_' underscores (re
> mod_cgi)
> c) On Win32, all characters are UPPERCASE (implicitly done in mod_cgi by
> invoking CreateProcess(...) with the env block)

Thanks for the patch, however it adds a potentially huge overhead on each 
request (CPU cycles and memory).

Can you explain why do you want to make mod_cgi and mod_perl absolutely 
compatible? Earlies you have shown this example:

All the keys in UPPERCASE come from mod_cgi.


All the keys in MixedCase come from mod_perl.


Do you need to use any of those keys?

And this is obviously wrong to s/\W/_/ for all platforms, since if I set the 
env var Foo-Bar, I'd expect it to be Foo-Bar and not Foo_Bar. This change 
would be very confusing to non-win32 users.

I've checked the mod_perl 1.0 sources and no such manipulation was done there 
and I haven't heard any complaints about mod_perl 1.0 so far. I suppose that 
the whole problem started from the need to detach the C environ struct from 
perl's %ENV, because C's environ is not thread-local. Otherwise perl would 
take care of handling the key correctly, as it does in mod_perl 1.0. Can you 
please check whether this is an issue with mod_perl 1.0 as well?

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message