I don't think I explained myself well. You're telling me to solve a problem which I think exists with the uwsgi protocol, by doing stuff with the HTTP protocol. But the real way to solve it is by augmenting the uwsgi protocol. I'm not talking about uWSGI adding a "Content-Length" HTTP header, because indeed it can't know the true length of the response and it shouldn't do the webserver's job. But I AM talking about uWSGI adding a "uwsgi-content-length" header, because the uwsgi protocol is up to uWSGI.
In other words, the type of failure I'm talking about can not happen in a server like mod_wsgi, because it's in-process; there can be no communication failure between mod_wsgi and Apache. However, uWSGI lives outside of nginx, and has it's own protocol (which isn't HTTP, it just happens to look like HTTP for the case of modifier1==72, with 'TT' length and 'P' modifier2). The uwsgi protocol can and should protect against uwsgi-nginx failure, even if the HTTP protocol didn't add Content-Length or chunked encoding yet (for example, precisely because I want the webserver to handle this). I hope this makes it clearer, - Yaniv On Thu, Sep 29, 2011 at 8:48 PM, Roberto De Ioris <[email protected]> wrote: > > > -- > > Obviously you can bypass the problem doing the cache write within the app > itself (using memcached or something similar). Memcached is supported out > of the box by nginx. > > -- > 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
