[1.5.x] 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.

Backport of 3ce1d30.

Conflicts:
	docs/howto/deployment/wsgi/index.txt

docs/howto/deployment/wsgi/index.txt

@@ -71,3 +71,11 @@ application that later delegates to the Django WSGI application, if you want to
 combine a Django application with a WSGI application of another framework.
 
 .. _`WSGI middleware`: http://www.python.org/dev/peps/pep-3333/#middleware-components-that-play-both-sides
+
+.. note::
+
+    Some third-party WSGI middleware do not call ``close`` on the response
+    object after handling a request — most notably Sentry's error reporting
+    middleware up to version 2.0.7. In those cases the
+    :data:`~django.core.signals.request_finished` signal isn't sent. This can
+    result in idle connections to database and memcache servers.

docs/howto/deployment/wsgi/uwsgi.txt

@@ -34,6 +34,15 @@ command. For example:
 
 .. _installation procedures: http://projects.unbit.it/uwsgi/wiki/Install
 
+.. warning::
+
+    Some distributions, including Debian and Ubuntu, ship an outdated version
+    of uWSGI that does not conform to the WSGI specification. Versions prior to
+    1.2.6 do not call ``close`` on the response object after handling a
+    request. In those cases the :data:`~django.core.signals.request_finished`
+    signal isn't sent. This can result in idle connections to database and
+    memcache servers.
+
 uWSGI model
 -----------
 

docs/ref/signals.txt

@@ -447,17 +447,20 @@ request_finished
 
 Sent when Django finishes processing an HTTP request.
 
-.. note::
-
-    When a view returns a :ref:`streaming response <httpresponse-streaming>`,
-    this signal is sent only after the entire response is consumed by the
-    client (strictly speaking, by the WSGI gateway).
-
 .. versionchanged:: 1.5
 
-    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.
+    Before Django 1.5, this signal was sent before delivering content to the
+    client. In order to accommodate :ref:`streaming responses
+    <httpresponse-streaming>`, it is now sent after the response has been fully
+    delivered to the client.
+
+.. note::
+
+    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:
 

docs/releases/1.5.txt

@@ -442,7 +442,15 @@ generation.
 This signal is now sent after the content is fully consumed by the WSGI
 gateway. This might be backwards incompatible if you rely on the signal being
 fired before sending the response content to the client. If you do, you should
-consider using a middleware instead.
+consider using :doc:`middleware </topics/http/middleware>` instead.
+
+.. note::
+
+    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 the
+    ``request_finished`` signal isn't sent at all. This can result in idle
+    connections to database and memcache servers.
 
 OPTIONS, PUT and DELETE requests in the test client
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~