perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: [mp2.0] Win32 ENV still not compatible with mod_cgi
Date Thu, 08 May 2003 09:46:12 GMT

Take a couple of steps back and I'll explain my problem:-

1) I have a web-based system running on Linux, AIX, HP-UX, Tru64 and Win32
   apache, mod_ssl, Oracle, DBI (and a lot more). One of the environment
   that is used within our perl scripts is "SSL_SERVER_S_DN_Email" (note the
mixed case !!!).

2) We made a decision to move to mod_perl - to get all the performance

3) The perl scripts worked using ModPerl::Registry on the UNIX systems, but
the Win32
   version fails to extract "SSL_SERVER_S_DN_Email".

4) If we don't use mod_perl on Win32 - it works - albeit much slower.

I need to maintain a single source code set that will work with all these
systems. I've tried to come up with a work-around in our perl modules, but I
run into
the following simple problem on Win32 :-

always get
undef - as the variable name is internally stored as
"SSL_SERVER_S_DN_Email", but the
perl interpreter will always uppercase the key before attempting a lookup
and since
SSL_SERVER_S_DN_Email is NOT the same as SSL_SERVER_S_DN_EMAIL, it will
never find it.

Regarding CPU / memory:-

OK, as this is only a problem on Win32, why not put the whole patch around
an #ifdef
for the Win32 or caseless environment. That would not put any more
'pressure' on the
UNIX environments.

I'm not really bothered about '_' or '-', I just took the CGI code as-is
because it

Also, at the end of the day, if we are ultimately going to be running perl
scripts or
modules, then the performance 'saving' by not fixing the key names is
negligle as the
fixup is done is 'C' code as opposed to much slower perl code.

I'd rather have something that works (albeit marginally slower) than
something that
doesn't work at all...

As far as I was aware, I had responded to ALL of your e-mails / questions,
so I don't
know what you're getting at regarding :-

	"You haven't followed up on my further questions, so the other
things weren't 

Unfortunately, I don't have mod-perl 1.0 to try it out as we'd made a
decision to go
with apache2 before development started.


-----Original Message-----
From: Stas Bekman []
Sent: 08 May 2003 05:18
To: Sparling, Steve (PS, GENS)
Subject: Re: [mp2.0] Win32 ENV still not compatible with mod_cgi wrote:
> 1. Problem Description:
>  %ENV still not compatible with mod_cgi regarding mixed case variable
>  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
> problem.

It addresses the first problem with PassEnv, on which you said it worked
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
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