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