Il giorno 30/set/2011, alle ore 08:24, Yaniv Aknin ha scritto: > Well, you guys convinced me this is more of an nginx bug (a very serious > nginx bug, IMO!) than a uwsgi bug. The fact that nginx ignores the > Content-Length of the data it receives from the upstream is very strange to > me (http://forum.nginx.org/read.php?2,204853,205805#msg-205805). > > I could argue that uwsgi's protocol is not really HTTP 1.0, it's a different > protocol which happens to have a single packet that looks precisely like an > HTTP 1.0 response, and this problem could be solved by adding the "EOT" > marker that C Anthony described to the uwsgi protocol, not to the actual > content, but I understand now it would be better to try and engage nginx's > community about this than solve it particularly for uwsgi. > > The bottom line here is that if you use nginx, you must do end-to-end > body-length declaration from your app to the end client. nginx can't be > trusted to discover a disconnection in the body phase, and it can have > disastrous results, especially with transparent caching.
Sprry again Yaniv, but i fear you have not understand a fondamental point: there is not such thing like a "uwsgi protocol" for you response. uWSGI simply re-build the WSGI answer to a HTTP (1.0 or 1.1, it depends on the app itself) and send it to the webserver. You will find example of using uWSGI to build chunked response in async mode. This is possibile because uwsgi send back HTTP messages, not uwsgi one. Ading and EOT means changing the nginx (or whatever server) HTTP handler, so is not a viable solutions. And yes, i am agree nginx should fix this, as i have to admin, i am one of those guy not caring the Content-Length header :) -- Roberto De Ioris http://unbit.it JID: [email protected] _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
