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 called before the exec() call to the
CGI.


*** /usr/local/lib/python2.4/CGIHTTPServer.py   Tue Apr  4 11:13:23 2006
--- kCGIHTTPServer.py   Fri Dec 21 13:31:40 2007
***************
*** 227,232 ****
--- 227,233 ----
                      pass
                  os.dup2(self.rfile.fileno(), 0)
                  os.dup2(self.wfile.fileno(), 1)
+                 os.chdir(os.path.dirname(scriptfile))
                  os.execve(scriptfile, args, os.environ)
              except:
                  self.server.handle_error(self.request,
self.client_address)

Can you give some reference to demonstrate that this is the usual behavior?

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 script.
     * NB only ISINDEX scripts get decoded arguments.
     */
    if (((rc = apr_procattr_create(&procattr, p)) != APR_SUCCESS) ||
        ((rc = apr_procattr_io_set(procattr,
                                   e_info->in_pipe,
                                   e_info->out_pipe,
                                   e_info->err_pipe)) != APR_SUCCESS) ||
        ((rc = apr_procattr_dir_set(procattr,
                        ap_make_dirstr_parent(r->pool,
                                              r->filename))) !=
APR_SUCCESS) ||



apr_procattr_dir_set sets the cwd for the child subprocess
ap_make_dirstr_parent is equivalent to os.path.dirname.

As the default behavior is system-dependent, it should not be hardcoded
but some sort of hook should provided to allow implementing either the
UNIX or Windows semantics.

A small note from me:

Your proposed patch is no good and is going to lead to strange, hard to
debug bugs in your app. os.chdir() isn't safe in a threaded environment.
You must protect the entire section with a global lock.

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 a concurrent affair.

Is the reporter correct that it is not thread impacting?

yes the reporter is correct.

the suggested chdir happens in the subprocess.

however, that only works on posix systems:

windows currently uses popen2/3.  (see issue1535504 for another issue
with that).  switching to subprocess and passing in cwd would fix it.

and non-posix non-windows (what is that?) uses execfile to run the
script in process.  we can't fix that one, nor should be bother.  what
is a non-posix non-windows system that needs to run a cgi http server??

fyi - non-posix / non-windows platforms could include alternate python
VMs that don't support fork, popen2 or subprocess.

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 defeats the whole idea of
including it in the standard library.

Part of the problem is that the CGI spec isn't properly documented. A
great many early Internet standards were slapdashedly written up by
Netscape on web sites that were dropped by AOL eventually.

In the absence of the local docs claiming that cgiHTTPServer changes directory, this is a feature request that could only go into 3.2 or later. If I understand http.server.py, the successor does use subprocess, so G.P.Smith's suggestion in msg87067 might be implemented. However, it is not clear to me from the comments if the idea is accepted in principle or not.

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 we will ever get. Section 7 described the system-specific implementation notes, and 7.2 specifies UNIX in particular:

The current working directory
      The current working directory for the script SHOULD be set to the
      directory containing the script.

This is also the specified behavior for AmugaDOS and EBCDIC POSIX systems. Oddly enough, the RFC editor did not find it worthwhile to specify the behavior on Windows...