At 11:01 AM 11/30/04 -0800, Titus Brown wrote:
The only real problem in getting this to work was that wsgiServer.py expected *every* URL under /demo to be registered to demo_obj. I changed the wsgiServer.py code to allow for partial matches & munged the SCRIPT_NAME and PATH_INFO variables appropriately. I also added REQUEST_URI because Quixote uses it for a few things; this should probably be moved into QWIP.
I think I'm going to have to call that point out in the PEP somewhere. Technically, the PEP requires that SCRIPT_NAME and PATH_INFO be set, but I think perhaps some folks have missed the implications of that for the URL path space.
Perhaps something like this would do the trick:
""" Application Placement in Server URL Space -----------------------------------------
In order to generate correct SCRIPT_NAME and PATH_INFO variables, servers and gateways MUST treat an application's location as a URL path prefix. That is, servers and gateways:
* MUST determine the target application using a matching prefix of the request path (which then determines the value of SCRIPT_NAME).
* MUST take the remaining portion of the request path, and use it to determine PATH_INFO. (Note that the remainder must be empty or begin with a '/', otherwise the prefix match was invalid!)
* MUST assume that there are an infinite number of possible URL paths that may appear as a PATH_INFO suffix "beneath" the application's base URL
I think this is too restrictive. It's the natural way to do things in most cases, but there's no reason to enforce it. E.g., a mod_rewrite-like middleware might do any number of things; it's a use-at-your-own-risk proposition (with considerable risk, at least from my own mod_rewrite experiences), but it shouldn't be disallowed, and this appears to disallow that kind of code.
A particular use case came to my mind today. Imagine a login middleware -- it wants to allow login and logout, but otherwise interrupt the request cycle as little as possible. So, lets say an application requires login; maybe it sends a 401. The login middleware catches it, sees that it's configured for cookie-based (form) login, and turns it into a 200 with a login form. The user logs in, and goes to their original page. You want to customize the login form, so the form might be an application that doesn't belong to the login middleware (but uses conventional keys); the URL belongs to the originally-requested application, but the application being served is some other application. Or later, if they try to login but fail, their URL may still be pointing at the original application (useful if they were submitting a POST form, which you want to pass through to the original URL, and it's difficult to do that with a redirect-after-submit).
There's a bunch of other ways this could be factored, but a number of them involve dispatching to an application based on query string, or in some way where SCRIPT_NAME and PATH_INFO don't have any relation to the application at all.
So I'd say these should all be SHOULDs, not MUSTs. Or they should simply be put in as implementation recommendations. In general I don't think this should be a problem, because implementors will respond to feedback, and if it's really a problem it will be addressed (and probably fairly quickly). There's a lot of weird use cases for application dispatching, and I don't see any reason to restrict that by formalizing how dispatching should work.
Notice that these requirements imply that servers and gateways:
* MUST NOT use query string contents, fragment identifiers, or URL parameters to determine the application object that a request should be sent to.
* MUST NOT require that every URL path used by the application be preconfigured or pre-registered with the server, or have some required mapping to existing files, or any other requirement that would make dynamic URLs impractical.
A server or gateway that cannot meet these requirements IS NOT COMPLIANT with this specification; it would be completely unusable for applications from many popular Python web frameworks inlcuding at least Zope, Webware, and Quixote, and many standalone Python web applications as well.
"""
_______________________________________________ Web-SIG mailing list [EMAIL PROTECTED] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
