Re: [Python-Dev] wsgi validator with asynchronous handlers/servers

Hello,

first time here, I'm Luca and I write lots of python of the asynchronous
variety.
This question is about wsgi and the way pulsar
http://quantmind.github.com/pulsar/ handles asynchronous wsgi responses.

Yesterday I sent a message to the python-dev mailing list regarding
wsgiref.validator, this is the original message

I have an asynchronous wsgi application handler which yields empty bytes
before it is ready to yield the response body and, importantly, to call
start_response.

Something like this:

def wsgi_handler(environ, start_response):
        body = generate_body(environ)
        body = maybe_async(body)
        while is_async(body):
            yield b''
        start_response(...)
        ...

I started using wsgiref.validator recently, nice little gem in the standard
lib, and I discovered that the above handler does not validate! Disaster.
Reading pep 3333

"the application *must* invoke the start_response() callable before the
iterable yields its first body bytestring, so that the server can send the
headers before any body content. However, this invocation *may* be
performed by the iterable's first iteration, so servers *must not* assume
that start_response() has been called before they begin iterating over the
iterable."

The pseudocode above does yields bytes before start_response, but they are
not *body* bytes, they are empty bytes so that the asynchronous wsgi server
releases the eventloop and call back at the next eventloop iteration.


And the response was


>PJ Eby wrote:
> >> The validator is correct for the spec.  You *must* call
> >> start_response() before yielding any strings at all.
> >
> >
> > Thanks for response PJ,
> > that is what I, unfortunately, didn't want to hear, the validator being
> > correct for the "spec" means I can't use it for my asynchronous stuff,
> which
> > is a shame :-(((
> > But why commit to send headers when you may not know about your response?
> > Sorry if this is the wrong mailing list for the issue, I'll adjust as I
> go
> > along.
>
> Because async was added as an afterthought to WSGI about nine years
> ago, and we didn't get it right, but it long ago was too late to do
> anything about it.  A properly async WSGI implementation will probably
> have to wait for Tulip (Guido's project to bring a standard async
> programming API to Python).
>

and so here I am.
I know tulip is on its early stages but is there anything on the pipeline
about wsgi?
Happy to help if needed.

Regards
Luca