fcgi.py

[Victor Muslin]

Thanks, Robin. I was just thinking the same thing. Seems that for a
simple-minded fix changing

        s=socket.fromfd(sys.stdin.fileno(), socket.AF_INET,
                        socket.SOCK_STREAM)
        s.getpeername()
 
to

            s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            s.bind(('', port))          # bind to the localhost
            s.listen(1)

did the trick. Then I added a few more tweaks to allow specification of port as
a parameter to Accept() and tweaked the _test() function to allow specification
of port as a command line parameter for testing.

For anyone who may wish to use this module on WindowsNT the full source code may
be downloaded from http://pages.prodigy.net/victor/fcgi2_py. The directory
contains two files:

	fcgi2.py - modification of original Robin Dunn's fcgi.py
	fcgi2.fcgi - a sample config file for cgi-fcgi program

fcgi2.py can be tested by running it from a command line with or without a port
parameter as follows:

(1)	python fcgi2.py

or

(2)	python fcgi2.py -port 9001

If invoked as in (1) it should run the same way as the original fcgi.py. If
invoked as in (2) it should run as a daemon listening on localhost's port 9001.
For more detailed usage information run it as:

(3)	python fcgi2.py -?

On Wed, 27 Dec 2000 20:03:10 -0800, "Robin Dunn" <robin at alldunn.com> wrote:

>"Victor Muslin" <victor at prodigy.net> wrote in message
>news:3a4a90ab.1328483109 at localhost...
>> I just found an old posting that says that socket.fromfd() is not
>> implemented on Windows platform (though Python documentation does not
>> say so). Is there a FastCGI solution for Python for WindowsNT???
>>
>
>The fcgi.py module is written such that it expects to be started from a
>"FastCGI Environment" such as from mod_fastcgi in Apache or from cgi-fcgi.
>On Unix this means that the file descriptor for stdin is a listening socket
>pre-created by the parent process that the webserver will connect to in
>order to send requests to your fastcgi application.  It's done this way so
>mod_fastcgi can create multiple processes all listening on the same socket,
>not just the same port, but the same socket.  This is definitly a
>unix-thing.
>
>On the other hand if you don't mind losing the multiple process capability,
>fcgi.py could probably be tweaked to create its own listening socket instead
>of expecting it to already be there.  It could then be started up
>independently of the webserver, and on any machine.  With creative use of
>threads you can even regain most of the benefit of having multiple processes
>running, (start a new thread, or allocate one from a thread pool, for every
>connection to the socket.)
>
>--
>Robin Dunn
>Software Craftsman
>robin at AllDunn.com
>http://wxPython.org     Java give you jitters?
>http://wxPROs.com        Relax with wxPython!
>
>
>