[Web-SIG] Proposed WSGI extensions for asynchronous servers

[Christopher Stawarz]

On May 12, 2008, at 12:45 AM, Ionel Maries Cristian wrote:

> On Mon, May 12, 2008 at 3:25 AM, Christopher Stawarz <cstawarz at csail.mit.edu 
> > wrote:
> On May 11, 2008, at 7:05 PM, Phillip J. Eby wrote:
>
> For this to work, you're going to need this to take the wsgi.input  
> object as a parameter.  If you don't, then this will bypass  
> middleware that replaces wsgi.input.
>
> That is, you will need a way for this spec to support middleware  
> that's replacing wsgi.input, without the middleware knowing that  
> this specification exists.  In the worst case, it should detect the  
> replaced input and give an error or some response that lets the  
> application know it won't really be able to use the async feature.
>
> I hadn't considered middleware that replaces wsgi.input.  Is there  
> an example component you can point me to, just so I have something  
> concrete to look at?
>
> Given that the semantics of wsgi.input are, in general, incompatible  
> with non-blocking execution, I'm inclined to think that such  
> middleware would either need to be rewritten to use x- 
> wsgiorg.async.input, or just couldn't be used with asynchronous  
> servers.  But I'll think about it some more -- maybe there's a way  
> to make this work.
>
>
> Making input filters work could be achieved using greenlets - but  
> then again - if one would use greenlets he could use them to  
> simulate a seemingly blocking api for the input so this is pretty  
> much pointless.
>
> But I agree, detecting this is good and errors should be thrown in  
> this case.
> In cogen i'm setting wsgi.input to None - so any use of it would end  
> in a error - though it's not very elegant.

But if your server sets wsgi.input to None, then you really can't  
claim that it's WSGI-compliant.

It seems like the authors of asynchronous servers have two options for  
how to handle wsgi.input.  The first option is to provide a compliant  
wsgi.input (with file-like, blocking behavior).  This means that  
middleware that uses/replaces wsgi.input will work properly, but the  
whole server can block whenever such use takes place.  Therefore, apps  
and middleware will essentially be required to use x- 
wsgiorg.async.input.

The second option is to provide a non-compliant (i.e. non-blocking)  
wsgi.input, which works something like x-wsgiorg.async.input.  But  
then any middleware that uses wsgi.input will be broken, since it  
won't work as expected.

In either case, wsgi.input ends up being unusable.  Ugh.

Of course, there is an easy way out of this:  Drop the idea of x- 
wsgiorg.async.input, and push the responsibility for making wsgi.input  
non-blocking on to server authors.  In effect, this would mean that  
asynchronous servers must *always* pre-read the request body and  
provide it to the app as a StringIO (or whatever).

I would like to avoid this requirement, since the ability for servers  
to provide on-demand, non-blocking input to the application seems  
useful.  But if it comes down to a choice between (1) the ability to  
receive data from the client on-demand and (2) having a wsgi.input  
that can actually be used, I'm think I'd choose (2).


Chris