Bug 46751 - Can passenv variables who's name contain '(' or ')'
Summary: Can passenv variables who's name contain '(' or ')'
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_env (show other bugs)
Version: 2.2.24
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2009-02-21 13:01 UTC by Bill Sobel
Modified: 2016-04-08 16:42 UTC (History)
3 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Bill Sobel 2009-02-21 13:01:21 UTC
In Windows Vista and Windows 2008, many registry entries are now reg_expand_sz's which use environment variables substitution to resolve their actual path.  And example of this is the ADODB componets.  This means that cgi applications need to have the 'CommonProgramFiles' environment variable passed if they attempt to instantiate these components via COM.  This is common with PHP.

However,on 64bit platforms one must also pass the 'CommonProgramFiles(x86)' environment variable if launching 32bit cgi programs. Apache's only allows alphanumerics in the name of environment variables passed and converts CommonProgramFiles(x86) to CommonProgramFiles_x86_  This means that the 32bit client does not have the correct environment setup and com can not expand the registry paths when attempting to instantiate components.

( and ) should be allowed in environment variable names.
Comment 1 Nick Kew 2010-07-05 16:19:57 UTC
AFAICT there's nothing in mod_env to preclude your choice of name if the platform is happy with it.  But I don't have a windows box to test on.

Are you sure it isn't just a matter of needing to escape your brackets?
Comment 2 Bill Sobel 2012-02-03 16:49:03 UTC
When I had traced the code, there was a loop that only allowed alphanumerics and changed anything else into the _ character causing the issue.  There did not appear to be any way to escaper the characters to prevent this code from modifying the string.
Comment 3 Polecat 2013-05-04 22:49:20 UTC
Title:  Can't Set or Pass Environment Variables who's names contain special characters '(' or ')'. 

When I set the parameters in httpd.conf to pass Windows 7 x64 bit environment variables to CGI based applications, then as stated before, if they contain any special characters, then these characters are replaced with underscores "_".  This can cause CGI applications which are x32 based running on an x64 based OS to fail, as the underlying components cannot discern the correct x32 path to the necessary libraries. 

Example:  httpd.conf file with a virtual host settings to pass env. variables.

<VirtualHost myserver.homesite.com:80>

PassEnv ProgramFiles
PassEnv ProgramFiles(x86)
PassEnv CommonProgramFiles(x86)
PassEnv CommonProgramFiles
PassEnv CommonProgramFilesW6432


Debug Output of passed Environment variables to the CGI app: 
Note the replacement of (x86) with _86_  in the Variable Names.
ProgramFiles=C:\Program Files (x86)
ProgramFiles_x86_=C:\Program Files (x86)
CommonProgramFiles_x86_=C:\Program Files (x86)\Common Files
CommonProgramFiles=C:\Program Files (x86)\Common Files

After having our CGI apps. work flawlessly for years with Windows XP on Apache, the following errors were seen immediately after upgrade to Win 7 x64. 

The following error was encountered at the point the CGI app. initiated a call for ADO to action (which then called the underlying OS component), which was not found at the location indicated by the incorrect env. variable.  

Error in the following Subroutine:  LogonToDatabase
Error Number = -2147024770  Automation error
The specified module could not be found. 

After much research, and code testing, I have confirmed and verified the cause of the problem is Apache's substitution in the Environment Variable names for the (x86) with _x86_ .

Additional info:  
For those affected, there is a work around to this problem to apply Env. Variables in the CGI app. when it launches, but it's a kludge.  

There is a large potential for affected users in the Windows environment, as this affects any legacy VB app that uses ADO (Database) components and possible other COM based features.   


I hope it's a rather simple fix, as it would be a great benefit to address. Thanks. 

NOTE:  SetEnv is also impacted by this bug on Windows x64. 

SetEnv ProgramFiles "C:\Program Files"
SetEnv "ProgramFiles(x86)" "C:\Program Files (x86)"
SetEnv ProgramFilesW6432 "C:\Program Files"
SetEnv CommonProgramFiles "C:\Program Files\Common Files"
SetEnv "CommonProgramFiles(x86)" "C:\Program Files (x86)\Common Files"
SetEnv CommonProgramFilesW6432 "C:\Program Files\Common Files"

Results in CGI Debug app:

ProgramFiles=C:\Program Files
ProgramFiles_x86_=C:\Program Files (x86)
ProgramFilesW6432=C:\Program Files
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles_x86_=C:\Program Files (x86)\Common Files
CommonProgramFilesW6432=C:\Program Files\Common Files

Keywords:  PassEnv, SetEnv, Environment Variable, Windows 7 x64, CGI application, VB6, ADODB
Comment 4 John 2014-05-20 11:43:28 UTC
If you have a combination of windows x64, apache and a win32 cgi (exe) using ADODB you have the problem that the enviroment variable CommonProgramFiles(x86)is translated into CommonProgramFiles_x86_

Adodb needs that env-variable to find the software, so it ends there.

The problem lies in util_script.c (2.4.9)

AP_DECLARE(char **) ap_create_environment(apr_pool_t *p, apr_table_t *t)
        while (*whack != '=') {
            if (!apr_isalnum(*whack)) {
                *whack = '_';

I propose a Change into : 

        while (*whack != '=') {
            if (!apr_isalnum(*whack) && *whack != '(' && *whack != ')') {
                *whack = '_';

You also need the following in Httpd.conf:  

SetEnv ProgramFiles "C:\Program Files"
SetEnv "ProgramFiles(x86)" "C:\Program Files (x86)"
SetEnv ProgramFilesW6432 "C:\Program Files"
SetEnv CommonProgramFiles "C:\Program Files\Common Files"
SetEnv "CommonProgramFiles(x86)" "C:\Program Files (x86)\Common Files"
SetEnv CommonProgramFilesW6432 "C:\Program Files\Common Files"

I tested the proposal with httpd 2.2 and httpd 2.4.9. Works fine.

Send me a message if you need the mod_cgi.so file


Comment 5 Christophe JAILLET 2016-01-03 14:27:45 UTC
This has been fixed in trunk in r1705217
Comment 6 Alexey Melezhik 2016-02-01 10:12:46 UTC

Conforming that this is issue is resolved ta my environment:

( https://github.com/melezhik/apache-swat is easy way to verify some existed apache issues on your environment )

vagrant@Debian-jessie-amd64-netboot:~/my/apache-swat$ swat  -t 46751/
/home/vagrant/.swat/.cache/11186/prove/46751/data.shtml/00.GET.t ..
ok 1 - GET succeeded
# http headers saved to /home/vagrant/.swat/.cache/11186/prove/Vmn8B65NaI.hdr
# body saved to /home/vagrant/.swat/.cache/11186/prove/Vmn8B65NaI
ok 2 - output match 'data 46751'
ok 3 - output match 'BAR(123)=123'
All tests successful.
Files=1, Tests=3,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.05 cusr  0.00 csys =  0.08 CPU)
Result: PASS

Apache compile info:

vagrant@Debian-jessie-amd64-netboot:~/my/apache-swat$ sudo ~/apache/bin/apachectl -V
Server version: Apache/2.4.18 (Unix)
Server built:   Jan 30 2016 10:17:37
Server's Module Magic Number: 20120211:52
Server loaded:  APR 1.5.1, APR-UTIL 1.5.4
Compiled using: APR 1.5.1, APR-UTIL 1.5.4
Architecture:   64-bit
Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D HTTPD_ROOT="/home/vagrant/apache/"
 -D SUEXEC_BIN="/home/vagrant/apache//bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.type
Comment 7 Yann Ylavic 2016-04-01 12:22:11 UTC
Backported to 2.4.20 in r1737360.
Comment 8 Gregg L. Smith 2016-04-08 16:42:45 UTC
Thanks Yann