[Web-SIG] Latest WSGI Draft

[Phillip J. Eby]

At 05:41 PM 8/22/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>Alright.  Let's make it 'wsgi.run_once'.  Here's my attempt at a shorter 
>>explanation:
>>``wsgi.run_once``      This value should be true if the server/gateway
>>                        expects (but does not guarantee!) that the
>>                        application will only be invoked this one time
>>                        during the life of its containing process.
>>                        Normally, this will only be true for a gateway
>>                        based on CGI (or something similar).
>
>Is there a reason it can't be guaranteed?

Is there a reason it *should* be guaranteed?  :)  The last time we had this 
discussion (December?), I thought you'd decided that the standard library's 
"atexit" facility was sufficient to cover your use case if a guarantee was 
needed here.  (I only just remembered the "atexit" discussion, or I'd have 
suggested that as the solution instead of introducing 'wsgi.last_call' a 
few days ago.)


>>Here's the use case I'm thinking of.  Suppose mod_python wants to expose 
>>some nifty super-duper API that an application can use in place of pure 
>>WSGI, if it's present.  But, this interface maybe bypasses certain 
>>features that a particular piece of middleware is intended to 
>>intercept.  So, my idea here is that if mod_python puts that API into a 
>>key in 'wsgi.extensions', then any middleware will know it's safely 
>>"intercepting communications" if it discards any 'wsgi.extensions'.
>>This is different from the sort of scenario you're talking about, where 
>>you can have cached data include a record of its dependencies to ensure 
>>correctness.
>>So here's the idea:
>>  * If you provide an alternative mechanism or extension to a 
>> WSGI-supplied facility, you place it in the 'wsgi.extensions' dictionary
>>  * If you're middleware that simply adds additional data to the 
>> 'environ', do so, recording your dependencies if any, to avoid becoming 
>> "stale" if other middleware changes things
>>  * If you're middleware that makes changes to existing variables, or 
>> intercepts any WSGI operations, do 'environ["wsgi.extensions"].clear()' 
>> or delete any extensions you can't intercept, to prevent the underlying 
>> application from "going around" you.
>>Your thoughts?
>
>Okay, that seems reasonable.  For instance, I could imagine mod_python 
>putting its Apache request object in an extension.  Something like an 
>exception-catching middleware wouldn't really care about this sort of 
>thing, so it wouldn't clear the extensions, but a middleware that filtered 
>the output wouldn't want that extension around.
>
>I guess a general rule would be that any extension that provided a route 
>around input/output should be in wsgi.extensions, and any middleware that 
>relies on input and output should clear those extensions.  Should that 
>rule also apply to the other environmental variables?

Actually, there's another way to handle this.  Suppose we put the burden on 
server authors to provide safe extensions?  Specifically, if a server 
provides an extension that can be used in place of, or as an extension to, 
any native WSGI facility (request data, response management, environment, 
etc.), then that facility *must* respect any changes made by middleware, or 
generate an appropriate error.

An example would be that if mod_python wanted to supply its request object 
as an extension, it would have to supply a variable like 
'mod_python.get_request', which would be a callable taking 'environ' and 
'start_response'.  If any 'environ' contents supplied by mod_python had 
changed, or 'start_response' wasn't the 'start_response' it gave to the 
application, it would have to either provide an alternative object, or 
raise an error, or return None, or something of that sort.  In other words, 
the burden of verification is on the extender.

This would simplify the spec somewhat, since we wouldn't need to introduce 
'wsgi.extensions', and we can also drop the suggestion for middleware 
authors to delete extensions.  Middleware is simpler too, it just changes 
what it needs to and moves on with life.  :)  We would just have to add a 
section on how to build "safe" extensions to the spec.