[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