Phillip J. Eby wrote: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.
You're focusing here on middleware; IMO the above is valid as long as it's applied only to servers and gateways, rather than middleware. It just needs a parenthetical to indicate that these restrictions don't apply to middleware.
_______________________________________________ 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
