RE: [Zope-dev] The Zope CGI executable, rewriting URLs on IIS
What exactly does the Win32 Zope CGI executable _do_?
I mean the one that comes with Zope and is stored as <installationname>.exe (eg., website.exe) under the web server directory you selected as part of the installation sequence. I assume it communicates with the Zope service, but how? Using HTTP?
Basically, the windows service/cgi.exe stuff is a holdover from the past, when PCGI didn't work on windows. The win32 service listens on a named pipe for connections from the cgi executable - the two communicate using the PCGI protocol. If you'd like, I can probably send you the service/cgi code - I'm sure that the powers that be here would love to see an ISAPI version of the cgi executable. Over time, I expect PCGI to obsolete this system, but there just haven't been enough resources to work on this lately :( While I'm pretty sure PCGI actually works now on win32, there is some work to do rolling it into the installation, documentation, etc.
The reason I ask is that I'd like to emulate the behaviour in an ISAPI filter DLL. The cool thing about filters is that your filter can grab all requests and preprocess them any way it likes.
I have already written a filter which rewrites URLs so that eg., "/QuickStart" becomes "/cgi-bin/zope.exe/QuickStart", and this works perfectly, except that Zope always forces <base href="..."> in documents, so only the initial document you refer to accepts this URL okay. All others go to the zope.exe URL. Even if I patch HTTPResponse.py to _not_ do this (which probably has major consequences for some apps, though), Zope often uses SCRIPT_NAME, PATH_INFO etc. for a lot of URLs, and my filter cannot modify these variables to reflect the "fake" URL. (Anybody with me so far?)
One solution would be to force Zope to always use a specific base URL, but I don't know even how to do this. Anyway I _presume_ that the CGI executable actually sends the path information to Zope, and so I need a little bit more information. Anyone?
I tried writing a (rather simple) filter once, but never really tried to tackle this problem. I assume that if you had an ISAPI thing calling the service though, it could probably munge the request a bit to do the right thing. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
[Brian Lloyd discusses win32 pcgi ...]
Over time, I expect PCGI to obsolete this system, but there just haven't been enough resources to work on this lately :( While I'm pretty sure PCGI actually works now on win32, there is some work to do rolling it into the installation, documentation, etc.
A caveat: PCGI on win32 is experimental and uses TCP/IP sockets (Unix version uses AF_UNIX IPC). A further refinement to the win32 version would probably use named pipes and require Mark Hammond's win32 extensions. Kudos to Amos for getting PCGI working with IIS. My preference is to use Apache/Win32 when using NT as a server, which is hardly ever. Best regards, Jeff Bauer Rubicon, Inc.
On 27 May 99, at 9:30, Jeff Bauer wrote:
A caveat: PCGI on win32 is experimental and uses TCP/IP sockets (Unix version uses AF_UNIX IPC). A further refinement to the win32 version would probably use named pipes and require Mark Hammond's win32 extensions.
In my opinion, moving to named pipes from TCP will be a step backwards. 1. Named pipes are slower than TCP connections 2. Named pipes (server side) are only available on NT, so you'll rule out use on Win9X. TCP/IP is the better way to go... Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937
participants (3)
-
Brad Clements -
Brian Lloyd -
Jeff Bauer