[Web-SIG] Proposed WSGI extensions for asynchronous servers
Phillip J. Eby
pje at telecommunity.com
Mon May 12 01:05:33 CEST 2008
At 06:15 PM 5/11/2008 -0400, Christopher Stawarz wrote:
>Non-blocking Input Stream
>The ``x-wsgiorg.async.input`` variable provides a non-blocking
>replacement for ``wsgi.input``. It is an object with one method,
>``read(size)``, that behaves like the ``recv`` method of
>``socket.socket``. This means that a call to ``read`` will invoke the
>underlying socket ``recv`` **no more than once** and return **at
>most** ``size`` bytes of data (possibly less). In addition, ``read``
>may return an empty string (zero bytes) **only** if the client closes
>the connection or the application attempts to read more data than is
>specified by the ``CONTENT_LENGTH`` variable.
>Before each call to ``read``, the application **must** test the input
>stream for readiness with ``x-wsgiorg.async.readable`` (see below).
>The result of calling ``read`` on a non-ready input stream is
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.
>If ``timeout`` seconds elapse without the file descriptor becoming
>ready for I/O, the variable ``x-wsgiorg.async.timeout`` will be true
>when the application resumes. Otherwise, it will be false. The value
>of ``x-wsgiorg.async.timeout`` when the application is first started
>or after it yields each response-body string is undefined.
Er, I think you are confused here. There is no way for the server to
know what environ dictionary the application is using, unless you
explicitly pass it into your extension API.
More information about the Web-SIG