[Web-SIG] Proposed WSGI extensions for asynchronous servers
Ionel Maries Cristian
ionel.mc at gmail.com
Mon May 12 06:45:22 CEST 2008
On Mon, May 12, 2008 at 3:25 AM, Christopher Stawarz <cstawarz at csail.mit.edu>
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Web-SIG