From: richard at folwell.com (Richard Folwell)
Date: Fri, 16 Apr 1999 20:01:32 GMT
Subject: stupid Win-CGI getting started question
Message-ID: <01BE8851.3B6BED90.richard@folwell.com>
Content-Length: 1800
X-UID: 209                                                  

On 14 April 1999 19:45, bill_seitz at my-dejanews.com 
[SMTP:bill_seitz at my-dejanews.com] wrote:
> So nobody can run .py files as CGI?
>
> Is this a known problem? What's its scope? Only Netscape/NT? What about IIS?

It was certainly possible to run .py files as CGI under IIS 2.  I did not need 
to upgrade that system, so cannot be sure about later versions of IIS, but 
would find it extremely hard to believe that anyone would remove the ability to 
use an abitrary external program to provide a CGI resource to a web server from 
a mainstream web server.

I do remember seeing a (at least one, maybe more) posting about differences in 
configuring IIS2/3/4 w.r.t. external programs (e.g. stuff which worked fine 
under IIS2/3 stopped working when the server was upgraded to version 4).

The problem has to be along these lines.  The CGI spec (I understand) simply 
requires programs/languages that can handle standard input (stdin) and produce 
standard output (stdout).

> I'm trying to keep my code generic enough that it can be moved to other
> platforms/servers down the road (which is why I haven't been looking at nsapy
> or Medusa or ZopeHTTP...), so I don't want to work around a problem now and
> just have it hit me again later. I'd like to understand the nature of the
> problem enough to evaluate alternative solutions.

I have done some work with ISAPI (the Microsoft equivalent to NSAPY).  There 
are performance gains with these approaches, but you definitely lock yourself 
into a single web server supplier (unless someone has come up with a neat way 
of producing cross-platform support for these plug-ins).  CGI has the big 
advantage that it is supported by all non-toy web servers, and the actual code 
should not need changing between different web servers.

Richard