On Mon, May 12, 2008 at 3:25 AM, Christopher Stawarz <[EMAIL PROTECTED]> 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. -- http://ionelmc.wordpress.com
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
