On Windows a path can contain spaces (e.g. C:\Program Files\python22
\python.exe). If using popenx each component in a command line has 
therefore to be double quoted as well as the whole command string.
The method run_cgi() of the class CGIHTTPRequestHandler in the module 
CGIHTTPServer does not do this.

Therefore the line 236:
cmdline = "%s -u %s" % (interp, cmdline)
should be replaced by
cmdline = '""%s" -u "%s""' % (interp, cmdline)

Please submit a patch -- this was mostly intended as demo code, I didn't
expect anyone to use it, let alone on Windows. :-)

The quoting issue on Windows can easily be fixed by using subprocess
instead of popen()

Hello,

I am new to Python issues tracker. I had the error described above. I
worked on it.

I was not able to solve the issue only using subprocess. The command has
to be correctly formated (with the double quotes).

I corrected the cmdline definition as described first and migrated from
popen2 and popen3 to subprocess. I don't think I have the rights to
commit any code so I send the modified file.

Don't hesitate to tell me if you want me do to more.
Regards,

Stac

PS : For information, the attached file correct the following error :

localhost - - [21/Oct/2009 17:20:52] "POST /cgi/test.py HTTP/1.1" 200 -
localhost - - [21/Oct/2009 17:20:52] command:
C:\Produits\Python26\python.exe -u C:\Documents and
Settings\stac\workspace\PyToolkit\src\network\cgi\test.py ""
localhost - - [21/Oct/2009 17:20:53] C:\Produits\Python26\python.exe:
can't open file 'C:\Documents': [Errno 2] No such file or directory

Now you have :
localhost - - [21/Oct/2009 16:48:46] "POST /cgi/test.py HTTP/1.1" 200 -
localhost - - [21/Oct/2009 16:48:46] command:
C:\Produits\Python26\python.exe -u "C:\Documents and
Settings\stac\workspace\PyToolkit\src\network\cgi\test.py" ""
localhost - - [21/Oct/2009 16:48:47] CGI script exited OK

Salut,

Note that in py3k, CGIHTTPRequestHandler (Lib/http/server.py) already
switched to using subprocess.

AFAICT, you didn't actually change cmdline, and so the problem remains.

Oups,

I really feel sorry.
Well here is a version with the modified cmdline.
I will check how the migration was done in py3k. 

Just a quick question : why the changes done in py3k was not reported to
py2.x ?

Regards,

Stac

Ok,

I corrected the two versions.
Now the one for py2.x is closer to the fix for py3k.
You'll find below the fixed code for both version.

Regards,

Stac

The original problem reported concerned spaces in the path of the python
executable.  So interp needs to be in quotes, as well (as Andy already
suggested).  I've created a patch against the latest py3k, which I've
confirmed works and fixes this issue.

I'm not a core developer, so I don't know why it wasn't backported. I
don't know if this will make it into 2.6. Maybe trunk?

More elegant than using quotes in the cmdline string is, IMO, passing a
sequence to subprocess.Popen instead.  I've put a new patch up for
review: http://codereview.appspot.com/141050

I've also unified the Unix and Windows portions in run_cgi.  Both now
use subprocess.  (Which on Unix still calls fork and exec, as before.)

drukker: I verified your patch. Looks fine for changes made to the
subprocess call. 

You mentioned: I've also unified the Unix and Windows portions in
run_cgi.  Both now use subprocess."
I don't see it in the patch. Was it that you assumed changing the
variable to from cmdline to 'args' makes it unified for windows and
linux? But it does not.

Irrespective, this report can be addressed by the changes you suggested.

orsenthil: I reverted the changes that make Windows and Unix use the
same code in Patch Set 3, and briefly mentioned the reason for that in
the Rietveld app.  I should have mentioned it here too.

It was because it actually makes the implementation on Unix worse, since
the Windows implementation reads all data in memory.  (The subprocess
module documentation has this note: "The data read is buffered in
memory, so do not use this method if the data size is large or unlimited.")

I tried replacing subprocess.PIPE with rfile/wfile, but it turns out
that that won't work, because on Windows socket.fileno() cannot be used
where file descriptors can be used, as the socket module documentation
states.

Committed revision 76208 in trunk.  Shall look at the output of windows
buildbots and merge the changes to other codelines.

Committed revision 76209 - release26-maint
Committed revision 76210 - py3k
Committed revision 76211 - release31-maint

Thanks Derk for the patch.

This change causes failures in test_httpservers on trunk r76211 on
Windows. I attached a simple patch which fixes the problem (NameError on
'p').

Thanks for the notification. Seems I over looked it. Fixed it with the
changes in 76212 (trunk) and 76213 (release26-maint). py3k did not have
this issue.