2011/9/29 Yaniv Aknin <[email protected]>: > I'm happy you understand me now. > The problem is if I fix it the HTTP way, it means my WSGI app has to do > things that are the webserver's job (like gzip compression). > For example, I tried sending a 1,000 byte document with correct > Content-Length from my app, via nginx with gzip compression on. If I kill > the connection at the 500th byte, nginx happily ignores the fact it has a > 500 byte document with Content-Length of 1,000 bytes, removes the > Content-Length header, does gzip and adds chunked transfer encoding.
This is indeed an nginx issue. Btw did you tried latest nginx? If it not works in latest nginx then possible workaround: * write a patch for nginx * disable gzip and pass content-length provided by wsgi app directly (maybe with uwsgi_pass_header) to browser the browser will show that a page don`t loaded.. dont know if it will cache. but still this is 200 ok. if you want 500 you have to teach nginx recognize that this is incomplete response. Also wsgi application may not provide already gzipped or transfer encoded content this is described in http://www.python.org/dev/peps/pep-0333/#other-http-features and http://www.python.org/dev/peps/pep-0333/#handling-the-content-length-header > 2. Answering "fix your app so uwsgi will not die" is not a serious response > in my opinion. Maybe my app had a bug, maybe uWSGI had a bug, maybe any of > the libraries they use had a bug, maybe my kernel had a bug, maybe my system > administrator made a mistake. This is a possibility that I don't think you > can seriously ignore, and not necessarily something I can fix. I prefer a > 502 in production instead of an incorrect 200 OK anyday. > This is a serious and complicated issue, I'd be happy to meet in IRC and > further explain this to those interested. Sorry Yaniv, maybe i misunderstood you point a bit. But still: If you app have a bug: try/catch it. If a bug in kernel: nothing will help you really. The system administrators do really make errors :) Although i agree with you: sad that nginx doesn't support checking of body response against content-length header. Also i think this issue can be solved with a proper support of ETag by nginx - so that ETag of incomplete response and complete will differ, but this is more like workaround. > So my app did everything OK in the HTTP way, but still the client has no way > of knowing something went wrong :-/ > Try running my test app with nginx and gzip compression, see how nginx > ignores my Content-Length... > I don't see a way to solve this other than changing the uwsgi protocol so > the response phase will have non-HTTP framing, so nginx will be able to know > when communications with uWSGI ended in an incorrect manner. I know this is > a big change, but I don't know what else to suggest. > - Yaniv > > On Thu, Sep 29, 2011 at 10:06 PM, Roberto De Ioris <[email protected]> wrote: >> >> > Evgeny, again, you missed my point. I don't want uWSGI to add an HTTP >> > header. I want it to fix the uwsgi protocol, not by adding HTTP headers, >> > by >> > fixing the uwsgi protocol. >> >> >> Ehm, Yaniv sorry for the mess, i should have clarified earlier, but uwsgi >> protocol is only for request. The response is a fully HTTP one (or a CGI >> one, with the Status header). >> >> So you have to fix it in the HTTP way. >> >> For modifiers that speak uwsgi protocol even for the response phase (like >> the RPC one) the size of the packet is specified in the header. >> >> >> -- >> Roberto De Ioris >> http://unbit.it >> _______________________________________________ >> 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 > > -- -------------------------------------------- Турнаев Евгений Викторович +7 906 875 09 43 -------------------------------------------- _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
