[Web-SIG] Request for Comments on upcoming WSGI Changes

[Graham Dumpleton]

2009/9/22 Ian Bicking <ianb at colorstudy.com>:
> On Tue, Sep 22, 2009 at 12:21 AM, Graham Dumpleton
> <graham.dumpleton at gmail.com> wrote:
>>
>> That may be fine for pure Python web servers where you control the
>> split of REQUEST_URI into SCRIPT_NAME and PATH_INFO in the first place
>> but don't have that luxury in Apache or via FASTCGI/SCGI/CGI etc as
>> that is done by the web server. Also, as pointed out in my blog,
>> because of rewrites in web server, it may be difficult to try and map
>> SCRIPT_NAME and PATH_INFO back into REQUEST_URI provided to try and
>> reclaim original characters. There is also the problem that often
>> FASTCGI totally stuffs up SCRIPT_NAME/PATH_INFO split anyway and
>> manual overrides needed to tweak them.
>
> When things get messed up I recommend people use a middleware
> (paste.deploy.config.PrefixMiddleware, though I don't really care what they
> use) to fix up the request to be correct.  Pulling it from REQUEST_URI would
> be fine.
> Also, at worst, you can do environ['SCRIPT_NAME_RAW'] =
> urllib.quote(environ.pop('SCRIPT_NAME')).  It sucks, but if that's all the
> information you have, then that's all the information you have.  Or try to
> get the information from REQUEST_URI the hard way, once at the gateway
> level.

Probably doable to just reverse it using underlying raw bytes. At
least in mod_wsgi the SCRIPT_NAME/PATH_INFO split is always correct,
unless people really screw it up by using WSGIScriptAliasMatch or
AliasMatch wrongly.

If doing something like you suggest, would prefer them as 'wsgi.'
prefixed variables and not put in all upper case namespace to be
confused with CGI variables etc.

Graham

Graham