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. 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
