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

[Aaron Watters]

I had to implement something like this for WHIFF.

I think path dispatch considerations do not belong at the level
of the WSGI spec.  Higher level layers should worry about
exactly how the URL gets dispatched within the application.
The higher layers can add environment entries as needed,
like  "whiff.entry_point" and "whiff.template_path" etc.

Or maybe I misunderstand something.  -- Aaron Watters

--- On Wed, 1/6/10, Gustavo Narea <me at gustavonarea.net> wrote:

> From: Gustavo Narea <me at gustavonarea.net>
> Subject: Re: [Web-SIG] wsgiorg.routing_path addition to the wsgiorg.routing_args Specification
> To: web-sig at python.org
> Date: Wednesday, January 6, 2010, 5:42 AM
> 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 |
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/arw1961%40yahoo.com
>