[Web-SIG] WSGI Utils & SCGI/Quixote.

[Ian Bicking]

Phillip J. Eby wrote:
> 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.
> """