Hello everybody. The current wsgiorg.routing_args specification requires that "Portions of the path that have been parsed should still be moved to SCRIPT_NAME (and removed from PATH_INFO)", but:
1.- That's against semantics. According to PEP 333 and the CGI spec, SCRIPT_NAME and PATH_INFO must represent the path where the (WSGI) application is "mounted" and the location of the request's target, respectively. 2.- It's not possible to reconstruct URLs reliably. After these variables have been modified, any attempt to reconstruct the home page's URL will be erroneous, for example. 3.- PATH_INFO will end up useless in many requests. For example, if a request matches the pattern "/posts/{article_title}/", these variables would have the following values: SCRIPT_NAME = "/blog/posts/hello-world" PATH_INFO = "/" I understand the reasoning behind a "cleaner" path, but I think taking data out of the PATH_INFO is not the best approach. Even if we only remove the matches alone, retaining the characters in between (instead of taking everything up to the last position of the match), we'd only be solving the third problem. So I'd like to propose the introduction of a new variable in the WSGI environment, wsgiorg.routing_path, which would be the PATH_INFO with all the arguments removed. Dispatchers would not have to modify SCRIPT_NAME or PATH_INFO. Instead, they should: 1.- Take the arguments from PATH_INFO and put them into wsgiorg.routing_args (as they do now). 2.- Store the PATH_INFO without arguments in wsgiorg.routing_path. Example 1 --------- Pattern = "/posts/{article_title}/" PATH_INFO = "/posts/hello-world/" wsgiorg.routing_args = ((), {'article_title': "hello-world"}) wsgiorg.routing_path = "/posts/" Example 2 --------- Pattern = "/posts/{article_title}/edit" PATH_INFO = "/posts/hello-world/edit" wsgiorg.routing_args = ((), {'article_title': "hello-world"}) wsgiorg.routing_path = "/posts/edit" This information would be useful in a number of situations, such as: 1.- An authorization framework could allow developers to write access controls based on the arguments-free path (i.e., wsgiorg.routing_path) and then use the arguments (in wsgiorg.routing_args) for more specific controls (if any). 2.- Templates can change automatically depending on the arguments-free path. .. which are not possible at present. What do you think about this? Cheers. -- Gustavo Narea <xri://=Gustavo>. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | _______________________________________________ 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