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

[Phillip J. Eby]

At 01:20 PM 12/2/04 -0600, Ian Bicking wrote:
>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.