[Web-SIG] wsgiorg.routing_path addition to the wsgiorg.routing_args Specification

[Gustavo Narea]

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 |