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
