[Web-SIG] wsgiorg.routing_args and original SCRIPT_NAME

Manlio Perillo manlio_perillo at libero.it
Mon Jan 28 12:55:38 CET 2008


Ian Bicking ha scritto:
 >
> [...]
>
>> 1) Do not change SCRIPT_NAME, and instead add a wsgiorg.consumed_path, a
>>     list.
>>
>>     This means that the request uri recostruction must be changed:
>>     SCRIPT_NAME = SCRIPT_NAME + '/'.join(wsgiorg.consumed_path)
> 
> I suppose you could leave stuff on PATH_INFO.  But that doesn't seem to 
> fit with the idea of PATH_INFO.  Also, will it be strictly 
> SCRIPT_NAME/consumed_path/PATH_INFO, or could it be 
> SCRIPT_NAME/consumed_path/some_other_parsing/consumed_path/PATH_INFO -- 
> after all, there's cases where stuff gets pushed from PATH_INFO to 
> SCRIPT_NAME, and if consumed_path is in between, which one do you push 
> stuff to?
> 

What do you intend by some_other_parsing?

>> 2) Store a wsgiorg.original_script_name, with the value seen by the
>>     routing application.
> 
> I guess I usually do something like this, typically storing 
> myapp.base_path for use when I am generation application-absolute URLs 
> (like /logout).  Then at the first chance (before running any kind of 
> routing) I do "environ['myapp.base_path'] = environ['SCRIPT_NAME']".
> 

Thanks, this seems an easy solution.

> This ad hoc technique works fine, but is very ad hoc.  I'm not sure what 
> the best way to handle this is, really.  I'm not sure there's a singular 
> root for an entire request, if you are nesting applications, so a single 
> key (wsgiorg.original_script_name) doesn't seem quite right.
> 

Right, this is a problem: what "root" actually means.

> I can't remember what Routes does for URL generation.  Maybe it leaves 
> SCRIPT_NAME alone?  I think so.
> 
>   Ian
> 



Manlio Perillo


More information about the Web-SIG mailing list