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

[Gustavo Narea]

Is it a really bad suggestion? :(

 - G.

On Mon, Jan 4, 2010 at 11:31 PM, Gustavo Narea <me at gustavonarea.net> wrote:

> 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 |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100106/e869d724/attachment.htm>