[Web-SIG] IIS and Python CGI - how do I see more than just the form data?

[And Clover]

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:and at doxdesk.com
http://www.doxdesk.com/