On May 12, 2008, at 12:45 AM, Ionel Maries Cristian wrote:
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.
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
_______________________________________________
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
