Fazal Majid added the comment:
Well, CGI/1.1 was formally documented by RFC 3875 in October 2004 (a full 11
years after CGI was introduced...).
http://www.rfc-editor.org/rfc/rfc3875.txt
The RFC is classified as "informative", but it's as close to a definitive spec
for CGI as w
Fazal Majid added the comment:
The problem is that in the current implementation there is no hook to
allow overriding any setup prior to exec, so the only way to produce the
standard UNIX behavior assumed by many scripts is to copy-paste the code
and patch it manually, which is very crude and
Fazal Majid added the comment:
I am experiencing the same problem with 2.6.2, whether using parallel
make or not, but 2.6.1. builds just fine.
--
nosy: +majid
___
Python tracker
<http://bugs.python.org/issue5
Fazal Majid added the comment:
MT-safety has nothing to do with this. The os.chdir() is invoked from
the new child process that is forked just prior to calling execve() to
run the CGI script, after which it exits. The parent CGIHTTPServer may
be multithreaded, but invoking the CGI script is not
Fazal Majid added the comment:
There isn't any normative reference that I know of, in fact the default
behavior is different on Unix and Windows.
Apache 2.2 (and most certainly older versions as well) implements this
in mod_cgi.c. The relevant lines:
/* Transmute ourselves into the s
New submission from Fazal Majid:
The CGI specification does not specify the working directory the CGI is
invoked in, but the usual behavior is to use the directory containing
the script.
CGIHTTPServer should either change working directory by default (see
patch below), or offer a hook to be
