[Web-SIG] The rewritten WSGI pre-PEP

[Phillip J. Eby]

At 12:51 PM 8/11/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>>====================   =============================================
>>>>Variable               Value
>>>>====================   =============================================
>>>>``wsgi.version``       The string ``"1.0"``
>>>
>>>
>>>Would it make sense for this to be a tuple, like (1, 0), like 
>>>sys.version_info?
>>
>>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 
>be rewritten.

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.  :(