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">&lt;<a href="mailto:me@gustavonarea.net">me@gustavonarea.net</a>&gt;</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 &quot;Portions of the<br>
path that have been parsed should still be moved to SCRIPT_NAME (and removed<br>
from PATH_INFO)&quot;, but:<br>
<br>
 1.- That&#39;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 &quot;mounted&quot; and the location of the request&#39;s target, respectively.<br>
 2.- It&#39;s not possible to reconstruct URLs reliably. After these variables<br>
have been modified, any attempt to reconstruct the home page&#39;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 &quot;/posts/{article_title}/&quot;, these variables would have the<br>
following values:<br>
  SCRIPT_NAME  = &quot;/blog/posts/hello-world&quot;<br>
  PATH_INFO = &quot;/&quot;<br>
<br>
I understand the reasoning behind a &quot;cleaner&quot; 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&#39;d only be solving the<br>
third problem.<br>
<br>
So I&#39;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 = &quot;/posts/{article_title}/&quot;<br>
PATH_INFO = &quot;/posts/hello-world/&quot;<br>
wsgiorg.routing_args = ((), {&#39;article_title&#39;: &quot;hello-world&quot;})<br>
wsgiorg.routing_path = &quot;/posts/&quot;<br>
<br>
Example 2<br>
---------<br>
Pattern = &quot;/posts/{article_title}/edit&quot;<br>
PATH_INFO = &quot;/posts/hello-world/edit&quot;<br>
wsgiorg.routing_args = ((), {&#39;article_title&#39;: &quot;hello-world&quot;})<br>
wsgiorg.routing_path = &quot;/posts/edit&quot;<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 &lt;xri://=Gustavo&gt;.<br>
| Tech blog: =Gustavo/(+blog)/tech  ~  About me: =Gustavo/about |<br>
</font></blockquote></div><br>