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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
