From: Geoff T. <gta...@na...> - 2000-07-27 18:29:26
Attachments:
CGIAdaptor.py.diffs.txt
|
I had to jump through some serious hoops to get WebWare to run using the CGI adaptor under Microsoft's IIS 4.0 web server. Here are the non-obvious things I had to do: 1) Configure IIS to handle PATH_INFO and PATH_TRANSLATED according to the CGI specification, by running the following command: cscript adsutil.vbs SET W3SVC/1/AllowPathInfoForScriptMappings 1 This is lightly documented in http://support.microsoft.com/support/kb/articles/Q184/3/20.ASP 2) Use Gordon McMillan's Standalone utility, which is part of his Installer package, to convert WebKit.cgi into an executable program WebKit.exe. IIS apparently will not handle requests with additional path components after the name of the script, like "http://localhost/WebKit.py/foo/bar" where WebKit.py is a script, but will handle requests like "http://localhost/WebKit.exe/foo/bar" where WebKit.exe is an executable. This behavior is not documented anywhere as far as I can tell. In any case, using the Standalone utility probably results in a speed increase, so it's not such a terrible thing that I had to do this. In order to convert WebKit.cgi into WebKit.exe using the Standalone utility, I had to rename it to WebKit.py, and add "import socket" to the top of the file (I could have used a configuration file instead, but this was easier). Then I was able to successfully use Standalone to create the executable. 3) I had to make a bugfix to CGIHandler.py so that it would read stdin in binary mode and read exactly the number of characters specified in the CONTENT_LENGTH environment variable. This is a fix recommended in a Microsoft knowledge base article: http://support.microsoft.com/support/kb/articles/Q203/2/98.ASP I think this fix is probably generally a good idea for any web server. I've attached the diffs I made to CGIHandler.py. I haven't tested the change on any other servers besides IIS, but if it works, I recommend checking it into CVS. Actually, parts 1 and 2 this message might make a good README file to include in the WebWare distribution. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Chuck E. <ec...@mi...> - 2000-07-27 18:33:45
|
Geoff, Thanks for all your work in this area. I'm building a site right now that will most likely be deployed on IIS in the future (but for now I get to develop on Apache). We'll definitely incorporate your changes into the code and your notes into the docs. Thanks! -Chuck At 02:28 PM 7/27/00 -0400, Geoff Talvola wrote: >I had to jump through some serious hoops to get WebWare to run using the >CGI adaptor under Microsoft's IIS 4.0 web server. Here are the >non-obvious things I had to do: > >1) Configure IIS to handle PATH_INFO and PATH_TRANSLATED according to >the CGI specification, by running the following command: > >cscript adsutil.vbs SET W3SVC/1/AllowPathInfoForScriptMappings 1 > >This is lightly documented in >http://support.microsoft.com/support/kb/articles/Q184/3/20.ASP > >2) Use Gordon McMillan's Standalone utility, which is part of his >Installer package, to convert WebKit.cgi into an executable program >WebKit.exe. IIS apparently will not handle requests with additional >path components after the name of the script, like >"http://localhost/WebKit.py/foo/bar" where WebKit.py is a script, but >will handle requests like "http://localhost/WebKit.exe/foo/bar" where >WebKit.exe is an executable. This behavior is not documented anywhere >as far as I can tell. In any case, using the Standalone utility >probably results in a speed increase, so it's not such a terrible thing >that I had to do this. > >In order to convert WebKit.cgi into WebKit.exe using the Standalone >utility, I had to rename it to WebKit.py, and add "import socket" to the >top of the file (I could have used a configuration file instead, but >this was easier). Then I was able to successfully use Standalone to >create the executable. > >3) I had to make a bugfix to CGIHandler.py so that it would read stdin >in binary mode and read exactly the number of characters specified in >the CONTENT_LENGTH environment variable. This is a fix recommended in a >Microsoft knowledge base article: >http://support.microsoft.com/support/kb/articles/Q203/2/98.ASP > >I think this fix is probably generally a good idea for any web server. >I've attached the diffs I made to CGIHandler.py. I haven't tested the >change on any other servers besides IIS, but if it works, I recommend >checking it into CVS. > >Actually, parts 1 and 2 this message might make a good README file to >include in the WebWare distribution. > >-- > > >- Geoff Talvola > Parlance Corporation > gtalvola@NameConnector.com > > >*** d:\cvs\Webware\WebKit\CGIAdaptor.py Fri Jun 09 12:20:21 2000 >--- d:\Program Files\Webware\WebKit\CGIAdaptor.py Thu Jul 27 >13:45:57 2000 >*************** >*** 33,53 **** > from marshal import dumps, loads > > > debugging = 0 # set 1 if you want to see the raw response dictionary, > instead of a normal page > > > def main(): > import os, sys > > try: >! myInput = sys.stdin.read() > > dict = { > 'format': 'CGI', > 'time': timestamp, > 'environ': os.environ.data, # ce: a little > tricky. We use marshal which only works on built-in types, so we need > environ's dictionary > 'input': myInput > } > > # 2000-05-20 ce: For use in collecting raw request > dictionaries for use in Testing/stress.py > # Leave this code here in case it's needed again >--- 33,59 ---- > from marshal import dumps, loads > > > debugging = 0 # set 1 if you want to see the raw response dictionary, > instead of a normal page > > > def main(): > import os, sys > > try: >! if os.name=='nt': # MS Windows: no special translation of >end-of-lines >! import msvcrt >! msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY) >! msvcrt.setmode(sys.stdin.fileno(), os.O_BINARY) >! >! length = string.atoi(os.environ['CONTENT_LENGTH']) >! myInput = sys.stdin.read(length) > > dict = { > 'format': 'CGI', > 'time': timestamp, > 'environ': os.environ.data, # ce: a little > tricky. We use marshal which only works on built-in types, so we need > environ's dictionary > 'input': myInput > } > > # 2000-05-20 ce: For use in collecting raw request > dictionaries for use in Testing/stress.py > # Leave this code here in case it's needed again >*************** >*** 60,83 **** > (host, port) = string.split(open('address.text').read(), ':') > if os.name=='nt' and host=='': # MS Windows doesn't like > a blank host name > host = 'localhost' > port = int(port) > bufsize = 32*1024 # @@ 2000-04-26 ce: this should be > configurable, also we should run some tests on different sizes > > s = socket(AF_INET, SOCK_STREAM) > s.connect(host, port) > s.send(dumps(dict)) > s.shutdown(1) >- >- if os.name=='nt': # MS Windows: no special translation of >end-of-lines >- import msvcrt >- msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY) > > # read the raw reponse (which is a marshalled dictionary) > response = '' > while 1: > chunk = s.recv(bufsize) > if not chunk: > break > response = response + chunk > response = loads(response) # decode it > >--- 66,85 ---- |
From: Chuck E. <ec...@mi...> - 2000-09-25 16:40:34
|
Geoff, Regarding IIS, a friend of mine ran into the same problem you describe below, where a CGI script has to end in .EXE in order to be recognized as such. But he claims he was able to simply rename the script and put a #!perl at the top. e.g., no binary required. Can you confirm? -Chuck At 02:28 PM 7/27/00 -0400, Geoff Talvola wrote: >I had to jump through some serious hoops to get WebWare to run using the >CGI adaptor under Microsoft's IIS 4.0 web server. Here are the >non-obvious things I had to do: > >1) Configure IIS to handle PATH_INFO and PATH_TRANSLATED according to >the CGI specification, by running the following command: > >cscript adsutil.vbs SET W3SVC/1/AllowPathInfoForScriptMappings 1 > >This is lightly documented in >http://support.microsoft.com/support/kb/articles/Q184/3/20.ASP > >2) Use Gordon McMillan's Standalone utility, which is part of his >Installer package, to convert WebKit.cgi into an executable program >WebKit.exe. IIS apparently will not handle requests with additional >path components after the name of the script, like >"http://localhost/WebKit.py/foo/bar" where WebKit.py is a script, but >will handle requests like "http://localhost/WebKit.exe/foo/bar" where >WebKit.exe is an executable. This behavior is not documented anywhere >as far as I can tell. In any case, using the Standalone utility >probably results in a speed increase, so it's not such a terrible thing >that I had to do this. > >In order to convert WebKit.cgi into WebKit.exe using the Standalone >utility, I had to rename it to WebKit.py, and add "import socket" to the >top of the file (I could have used a configuration file instead, but >this was easier). Then I was able to successfully use Standalone to >create the executable. > >3) I had to make a bugfix to CGIHandler.py so that it would read stdin >in binary mode and read exactly the number of characters specified in >the CONTENT_LENGTH environment variable. This is a fix recommended in a >Microsoft knowledge base article: >http://support.microsoft.com/support/kb/articles/Q203/2/98.ASP > >I think this fix is probably generally a good idea for any web server. >I've attached the diffs I made to CGIHandler.py. I haven't tested the >change on any other servers besides IIS, but if it works, I recommend >checking it into CVS. > >Actually, parts 1 and 2 this message might make a good README file to >include in the WebWare distribution. > >-- > > >- Geoff Talvola > Parlance Corporation > gtalvola@NameConnector.com > > >*** d:\cvs\Webware\WebKit\CGIAdaptor.py Fri Jun 09 12:20:21 2000 >--- d:\Program Files\Webware\WebKit\CGIAdaptor.py Thu Jul 27 >13:45:57 2000 >*************** >*** 33,53 **** > from marshal import dumps, loads > > > debugging = 0 # set 1 if you want to see the raw response dictionary, > instead of a normal page > > > def main(): > import os, sys > > try: >! myInput = sys.stdin.read() > > dict = { > 'format': 'CGI', > 'time': timestamp, > 'environ': os.environ.data, # ce: a little > tricky. We use marshal which only works on built-in types, so we need > environ's dictionary > 'input': myInput > } > > # 2000-05-20 ce: For use in collecting raw request > dictionaries for use in Testing/stress.py > # Leave this code here in case it's needed again >--- 33,59 ---- > from marshal import dumps, loads > > > debugging = 0 # set 1 if you want to see the raw response dictionary, > instead of a normal page > > > def main(): > import os, sys > > try: >! if os.name=='nt': # MS Windows: no special translation of >end-of-lines >! import msvcrt >! msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY) >! msvcrt.setmode(sys.stdin.fileno(), os.O_BINARY) >! >! length = string.atoi(os.environ['CONTENT_LENGTH']) >! myInput = sys.stdin.read(length) > > dict = { > 'format': 'CGI', > 'time': timestamp, > 'environ': os.environ.data, # ce: a little > tricky. We use marshal which only works on built-in types, so we need > environ's dictionary > 'input': myInput > } > > # 2000-05-20 ce: For use in collecting raw request > dictionaries for use in Testing/stress.py > # Leave this code here in case it's needed again >*************** >*** 60,83 **** > (host, port) = string.split(open('address.text').read(), ':') > if os.name=='nt' and host=='': # MS Windows doesn't like > a blank host name > host = 'localhost' > port = int(port) > bufsize = 32*1024 # @@ 2000-04-26 ce: this should be > configurable, also we should run some tests on different sizes > > s = socket(AF_INET, SOCK_STREAM) > s.connect(host, port) > s.send(dumps(dict)) > s.shutdown(1) >- >- if os.name=='nt': # MS Windows: no special translation of >end-of-lines >- import msvcrt >- msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY) > > # read the raw reponse (which is a marshalled dictionary) > response = '' > while 1: > chunk = s.recv(bufsize) > if not chunk: > break > response = response + chunk > response = loads(response) # decode it > >--- 66,85 ---- |
From: Geoff T. <gta...@na...> - 2000-09-25 18:00:34
|
Chuck Esterbrook wrote: > Geoff, > > Regarding IIS, a friend of mine ran into the same problem you describe > below, where a CGI script has to end in .EXE in order to be recognized as > such. But he claims he was able to simply rename the script and put a > #!perl at the top. e.g., no binary required. > > Can you confirm? > > -Chuck I can't get that to work using IIS. I took a python script that worked correctly when called testcgi.py and renamed it to testcgi.exe and placed a #! line at the top, and I get this error: HTTP Error 401 401.3 Unauthorized: Unauthorized due to ACL on resource This error indicates that the credentials passed by the client do not have access to the particular resource on the server. This resource could be either the page or file listed in the address line of the client, or it could be another file on the server that is needed to process the file listed on the address line of the client. Please make a note of the entire address you were trying to access and then contact the Web server's administrator to verify that you have permission to access the requested resource. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |