PEP 3333 specifies that the python app "should" be able to call read()
on wsgi.input and receive the remaining input and that servers "should"
return an empty string when there is no (more) input. uWSGI doesn't
follow those recommendations when I try it with Nginx. You can try this
small test application:
def application(environ, start_response):
input = environ['wsgi.input']
print 'Reading...'
data = input.read()
print 'Data:', data
start_response('200 OK', [('Content-Type', 'text/html')])
return ['test']
It will print 'Reading...' and then block until the client times out,
regardless of whether you send a GET or POST.
I looked a bit inside the source code and uWSGI simply hands over the
connection from Nginx (wrapped in a File Object) to Python. Nginx will
keep the connection open while waiting for a reply, so there is no way
for the file object to detect when it has reached the "end". As far as I
can see, uWSGI would need to add a thin wrapper that takes care of these
things.
What do you think? Is this something uWSGI should do differently? Some
python libraries seem to clash with the current behavior.
--
Hampus Wessman
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
