Thanks Andrew. It seems like URL rewriting is exactly the way to create a CGI based "RESTful" WEB service using IIS.
I think one can map an .exe to a folder in IIS and thus remove the need for the .py extension in the URL. Though it would probably be fairly inefficient to execute a PY2EXE program with every web hit. I'm going to keep tinkering... Best Regards, JDM J.D. Main wrote: > I want to see the entire HTTP request with everything inside it. You won't get that as a CGI (or WSGI) application. It is the web server's job to parse the headers of the request, choose what host and script that maps to, and make them available to you (in the environ dictionary in WSGI, or the real environment variables in CGI). The server may perform additional processing on the input/output (eg. buffering and chunking). If you really need low-level detail you'll need to write your own HTTP server, or adapt one from eg. BaseHTTPServer. You almost never need that for normal web applications. > Does IIS actually pass that information to the CGI application or does it > just > pass the variables? For a query string as posted, IIS parses the initial HTTP GET command, extracts the path part of that, splits it, and puts the `?...` part in the variable `QUERY_STRING` for you. > how would my python parse the following: > http://someserver/someapp/someuser/someupdate?var1=Charlie Many people do this with URL rewriting, to turn that into something like: http://someserver/someapp.py?user=someuser&action=someupdate&var1= Charlie You don't get a standard URL rewriter in IIS 5 but there are many third-party options. Personally I hate URL rewriting and try to avoid it wherever possible, because IMO URL format should be in the domain of the application and not a deployment issue. Unfortunately, if you really want to get rid of the `.py` in the URL, you will need at least some rewriting, because IIS refuses to map files without an extension to script engines. You can make the extension `.p` or `.html` or something else if you like, but you can't get rid of it. http://someserver/someapp.py/someuser/someupdate?var1=Charlie This URL should be parsed into environ members: HTTP_HOST: someserver SCRIPT_NAME: /someapp.py PATH_INFO: /someuser/someupdate QUERY_STRING: ?var1=Charlie Unfortunately (again), IIS gets this wrong. It sets `PATH_INFO` to: /someapp.py/someuser/someupdate which is contrary to the CGI/WSGI specifications. If you want to sniff path parts as an input mechanism (to do URL routing yourself without rewriting), you will have to detect this situation (probably by sniffing SERVER_SOFTWARE) and hack a fix in. Some libraries and frameworks may do this for you. (Aside: even this is not certain. This wrong behaviour can be turned off using a little-known IIS config option. However, it's unlikely to be used in the wild, not least because the flag typically breaks ASP.) Unfortunately (yet again), it's not reliable to send any old characters as part of the path. Because of the poor design of the original CGI standard (carried over into WSGI), any `%nn` escape sequences get decoded before being dropped into SCRIPT_NAME/PATH_INFO (though not, thankfully, QUERY_STRING). This has the consequence that there are many characters that can't reliably be used in a path part, including slashes, backslashes, control characters, and all non-ASCII characters (since they go through a Unicode decode/encode cycle with what are almost guaranteed to be the wrong charsets). Stick with simple strings like `someuser`. Summary: IIS is a pain. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
