[Web-SIG] The rewritten WSGI pre-PEP
Phillip J. Eby
pje at telecommunity.com
Wed Aug 11 20:40:56 CEST 2004
At 12:51 PM 8/11/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>>``wsgi.version`` The string ``"1.0"``
>>>Would it make sense for this to be a tuple, like (1, 0), like
>>Maybe. I'm not sure it makes any difference. I could just as soon drop
>>versioning altogether and just use the presence or absence of feature
>>keys as the means of determining the version.
>I think of the version as something of a contract. The WSGI server author
>can't deny that they intended to implement the full spec if they include
>the version number. Also it could be used like HTTP 1.1 sometimes is,
>like you must include a Host header if you claim to be talking
>1.1. Similarly applications could require certain features if the server
>claims to talk, say, WSGI 1.1.
Fair enough. Unless anybody else has any input one way or the other, we'll
make it the tuple (1,0).
>I've had constant problems trying to backtrack through middleware (like
>mod_rewrite) to figure out how to create a URL that is internal to the
>application. I'd like to keep around some artifact indicating what the
>original URI was (e.g., REQUEST_URI); something that middleware
>specifically should not rewrite. Nor is there any real reason for it to
Hm. And SCRIPT_NAME is insufficient for this? I think I can see why
mod_rewrite would make this a problem, but ISTM that Python middleware
component could do rewrites that left SCRIPT_NAME "logically correct".
I'm more concerned that the presence of such a variable would encourage
people to use it in ways that would ignore "rewritten" variables, thus
breaking middleware. Meanwhile, the common solution I've seen to this
issue in web applications is to have configuration for where the
application is in URL-space.
>SERVER_ADDR and REMOTE_PORT also don't require any rewriting, and should
>just be passed through any middleware.
Are you sure? SERVER_ADDR might be different if the request is forwarded
to another machine, mightn't it? I seem to recall that mod_backhand does
some stuff with this. In any case it highlights the trouble with trying to
precisely pin down things that are already inherently
implementation-defined. Unfortunately, WSGI isn't really going to
eliminate all the environment introspecting and munging code that lives in
the various existing apps and frameworks today.
> Hmm... the CGI spec also leaves out any SSL variables. Those are, of
> course, all optional. But if the user connected via SSL, I think
> HTTPS=on should be required.
I'll add something about this, and maybe some sort of a general note about
the inherent implementation-specificness of CGI variables. :(
More information about the Web-SIG