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 m...@gustavonarea.net wrote:
From: Gustavo Narea m...@gustavonarea.net
Subject: Re: [Web-SIG] wsgiorg.routing_path addition to the
wsgiorg.routing_args Specification
To: web-sig@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 m...@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@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/arw1961%40yahoo.com
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
