Hanging on wsgi.input read() is an age old problem, it's inherent in the WSGI 1.0 spec, and therefore common across WSGI implementations.
http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html http://www.cherrypy.org/ticket/966 >From a pragmatic standpoint the practical easy answer is to only call read() >for methods PUT or POST, and use CONTENT_LENGTH if available. Would also be nice if WSGI had read( nbytes, timeout ) that would -- throw an exception and allow the application to abort the request on read timeout -- return 0 byte string or end-of-input sentinel if end of input reached Den Feb 5, 2011 kl. 5:36 AM skrev Hampus Wessman: > 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 _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
