Hi,
Newbie opinion here.
Since we are talking about Tulip and PEP 3156, I think it's high time we
address some of the design flaws in WSGI 1.0
One major problem with WSGI is that it can not handle true post-response
hooks.
The closest hack I found is this:
https://modwsgi.readthedocs.org/en/latest/developer-guides/registering-cleanup-code.html
As discussed by Graham Dumpleton here
https://groups.google.com/group/modwsgi/msg/d699a09b3b11b313
Although the response was returned to the client, It will still hold the
http connection open until __callback finishes.
While it's pretty common design pattern for a post-response hook in modern
Web world. I can think a few usage:
- User uploads file, return HTML says Upload OK, then Web worker continue
to transfer file to Amazon S3, which is slow and takes some time.
- After a series of user interaction on a web page, using the existing db
connection to write OLAP logs of later analysis.
- notify the http request to another ZMQ/XMPP connection
Currently, Celery is extremely popular (at least in Django or other
non-async web frameworks). But IMHO it's too heavy weight and copying
python data objects from a cluster of Web workers to another cluster of
task queue workers is not worth it.
Another problem is the good old CGI environ design. I can't help to ask?
Why?
Every HTTP header is transfered via envion, and capitalized with a HTTP_
prefix e.g. HTTP_HOST. There's some serious information loss here.
1. Actual header string case
2. header order
Since WSGI is higher level framework, I think it's time for us to deliver
the original header status in a SortedDict.
Again, as a newbie advice, we should take this chance of integrating PEP
3156 with a deadly simple WSGI 3.0 design:
def application(request):
ip = request.remote_ip
length = request.headers[Content-Length]
request.write(htmldone./html)
request.close()
db.log(length) # some post-response actions.
On Mon, Mar 25, 2013 at 9:08 AM, Guido van Rossum gu...@python.org wrote:
Hi Luca,
Unfortunately I haven't thought yet about the interactions between WSGI
and Tulip or PEP 3156. While I am pretty familiar with WSGI, I have never
used its async features, so I can't be much of a help. My best guess is
that we won't make any changes to WSGI to support PEP 3156 in Python 3.4,
but that once that is out, some folks will come up with an improved design
for WSGI that supports interoperability with standard async event loops.
OTOH, maybe you can read up on the PEP and check out the Tulip
implementation (http://code.google.com/p/tulip/) and maybe you can come
up with a suitable design for integrating PEP 3156 into WSGI? Though it may
have to be named WSGI 2.0 to emphasize that it is backwards incompatible.
--Guido
On Sun, Mar 24, 2013 at 2:18 PM, Luca Sbardella
luca.sbarde...@gmail.comwrote:
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
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
