[Web-SIG] IIS and Python CGI - how do I see more than just the form data?
jdmain at comcast.net
Sat Apr 17 17:20:34 CEST 2010
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...
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:
Many people do this with URL rewriting, to turn that into something like:
You don't get a standard URL rewriter in IIS 5 but there are many
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.
This URL should be parsed into environ members:
Unfortunately (again), IIS gets this wrong. It sets `PATH_INFO` to:
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
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
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.
mailto:and at doxdesk.com
More information about the Web-SIG