From 3ce1d303daa92ecb1bc3ba6344f1ec9746a79c70 Mon Sep 17 00:00:00 2001 From: Jaap Roes Date: Mon, 3 Jun 2013 15:53:04 +0200 Subject: Warned that `request_finished` isn't sent by some buggy setups. Older versions of uWSGI and Sentry's middleware do not adhere to the WSGI spec and cause the `request_finished` signal to never fire. Added notes to the appropriate places in the docs. Fixed #20537. --- docs/ref/signals.txt | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) (limited to 'docs/ref') diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt index e7270e1957..06ba2cb3e8 100644 --- a/docs/ref/signals.txt +++ b/docs/ref/signals.txt @@ -498,17 +498,20 @@ request_finished Sent when Django finishes processing an HTTP request. -.. note:: +.. versionchanged:: 1.5 - When a view returns a :ref:`streaming response `, - this signal is sent only after the entire response is consumed by the - client (strictly speaking, by the WSGI gateway). + Before Django 1.5, this signal was sent before delivering content to the + client. In order to accommodate :ref:`streaming responses + `, it is now sent after the response has been fully + delivered to the client. -.. versionchanged:: 1.5 +.. note:: - Before Django 1.5, this signal was fired before sending the content to the - client. In order to accomodate streaming responses, it is now fired after - sending the content. + Some WSGI servers and middleware do not always call ``close`` on the + response object after handling a request, most notably uWSGI prior to 1.2.6 + and Sentry's error reporting middleware up to 2.0.7. In those cases this + signal isn't sent at all. This can result in idle connections to database + and memcache servers. Arguments sent with this signal: -- cgit v1.3