[Web-SIG] Latest WSGI Draft

[Phillip J. Eby]

At 01:53 AM 8/23/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>Fine.  I just don't like it being anything other than a heuristic.
>>Suppose I'm running acceptance tests?  My CGI runner will say "you're 
>>being run only once", except then I'll run it again when the acceptance 
>>test tests another input.  But, I want the acceptance test to test the 
>>operation of the application when it's in "cgi mode", effectively.
>
>If you're running multiple unit tests in a single process, you aren't in 
>CGI mode, and you shouldn't set that key.  You're in some other mode. If 
>CGI mode really matters, the only test that is accurate is one where you 
>are actually launching a separate process.

Not if the purpose is to test the code branch that e.g. saves your sessions 
when it's run in CGI mode.

What I'm getting at here is that the purpose of this "CGI mode" is to tell 
the app to perform certain behaviors on a different heuristic 
pattern.  There's nothing about that, that requires a guarantee of being 
only run once.  I say that because a CGI application is going to get run 
more than once, anyway, so obviously whatever it does can be done more than 
once.  And, it's hard to test it if you need to run a new process every 
time it runs.


>>>I can see that working for extensions to the request, but what about 
>>>extensions to the response?  E.g., some mod_python extension could allow 
>>>for internal redirects -- a useful feature that won't fit into WSGI.
>>
>>Really?  Why not?  Let's say that mod_python provides the function, the 
>>app calls it, doesn't call 'start_response', and doesn't return an 
>>iterator.  What does middleware do?  Well, presumably it does nothing.
>>Definitely it does nothing if it's an output transformer, or if it just 
>>adds things to the request.  So, where's the problem?
>
>Well, let's say mod_python adds two extensions.  One is to do a local 
>redirect, the other is to do a recursive call.  The local redirect would 
>be in wsgi.extensions (if it existed), but the recursive call would 
>not.  With wsgi.extensions, the middleware would eliminate the local 
>redirect, and the application would be forced to use the recursive call 
>and write out the result of that.  Which is what you would want, because 
>then the middleware would have an opportunity to modify the output.

In that case, why not have the local_redirect function require the 
start_response callable as one of its parameters?  It can then refuse if 
the output has been captured by middleware.


>I still can't think of a good way to define wsgi.extensions or give rules 
>for what should go in there.  I can see some case for it, but since it's 
>vague I don't think it should be included in the spec. There's room to add 
>it later if it turns out to be important.

We don't need wsgi.extensions, we just need for servers and gateways to 
make their extension APIs middleware-safe, by verifying that things the 
APIs depend on haven't been changed by middleware.  I'll write up an 
explanation of this in the spec.