This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients loewis, v+python
Date 2010-11-22.08:04:10
SpamBayes Score 1.6138146e-11
Marked as misclassified No
Message-id <4CEA23F9.4050100@v.loewis.de>
In-reply-to <1290391420.52.0.792385538066.issue10483@psf.upfronthosting.co.za>
Content
> Martin, that is an interesting viewpoint, and one I considered, but
> didn't state, because it seems much too restrictive.  Most CGI
> programs are written in scripting languages, not compiled to .exe.
> So it seems the solution should allow for launching at least Perl and
> Python scripts, as well as .exe.

Notice that it does support launching Python scripts. I disagree that
Perl scripts need to be supported. The idea of CGI is really that
"programs" get run by the web server, with the notion of "programs"
clearly deviating from system to system. Window really doesn't support
"scripts" (in the hash-bang sense), and it isn't the function of
http.server to extend Windows here. At best, support for .bat files
might be negotiable, using cmd.exe to launch them (but I personally
would not).

Anybody who wants support for other kinds of scripts on Windows will
have to subclass CGIHTTPRequestHandler (and it might be useful to
simplify subclassing that class).

In any case, the bug as stated ("def executable is simply wrong")
has a clear resolution - make it match what the rest of the code
supports. Anything beyond that is a feature request.
History
Date User Action Args
2010-11-22 08:04:17loewissetrecipients: + loewis, v+python
2010-11-22 08:04:10loewislinkissue10483 messages
2010-11-22 08:04:10loewiscreate