> I don't think a RST will be sent if uWSGI crashes or dies with SIGKILL - I > did a sniff (on OSX) and saw FINs, not RSTs.
I do not know how OSX choose to work, but if a process holding a socket on Linux make some mess the inet layer will send a RST (you can see this behaviour expecially with nginx when you close the connection before reading post data). But this is not the point. You cannot rely on it, because there are tons of way to prematurely close a socket connection (some will report FIN, some RST, sometimes it became stale :P ) Check the just committed stats server, if it dies during data send you will get worong statistics and uwsgitop will raise an exception :( > > Also, since uWSGI knows when the WSGI application callable returned or has > been exhausted (StopIteration), I think it can know whether or not the > response is finished or not. uWSGI knows only that a bunch of data has been sent to the client, it cannot distinguish between headers, body, chunked encoding and so on. It send the headers before even generating the body, so to build the content-length it should buffer the whole body (and that is really bad for performance) Think about gzip encoding. We should take in account dozens of situation... but wait !! this is the job of the webserver ! :) You are using caching, that rely on good form of the data. If your app does not set content-length or chunked encoding and you have such requierements then you should fix it in the app itself. WSGI middleware are perfect for this scope (and very easy). Take in account that the django common middleware, do exactly this. By the way, this problem pratically beat in the head all of the standalone servers out there. Maybe finding an alternative approach to mark content as 'good' would be useful for all. But honestly i have no idea on how to do it :( -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
