I previously mentioned problems a user was having running Leonardo under Python 2.4 on Windows and that I'd narrowed it down to CGIHTTPServer and the environment not getting populated.
Looks like others have had the same problem.
Pierre-André Côté pointed me to this bug report and fix at SourceForge and Markus Schramm suggested subclassing CGIHTTPServer with this workaround:
# There seems to be a bug in Python 2.4.0, that I could reproduce under # Win98SE and WinXP Home SP1a (Python 2.3.4 works OK for both systems). # # The CGI variables are set inside the current process. Normally the # CGI script will be executed in a new subprocess, but without this # workaround the variables are not accessible there. # # Expected reason (some additional tests done): # os.popen3(..) and os.popen4(..) do not correctly pass the modified # os.environ to the new subprocess (Windows platforms only). # # Workaround: # Redefine some class variable values to force a fallback mode that # executes the CGI script in the current process. # if 'win' in sys.platform and sys.version_info >= (2, 4): have_fork = have_popen2 = have_popen3 = False
Markus also suggested the following override (unrelated to the lost environment problem)
# Overridden to not call socket.getfqdn(host), that doesn't work at # all machines and is very very time consuming (several seconds) then. # Note: Merely used for logging to the console. # def address_string(self): return '%s:%s' % self.client_address2
Thanks also to Jeff de Wet.