diff --git a/docs/howto/deployment/wsgi/index.txt b/docs/howto/deployment/wsgi/index.txt
index 769d406b1b..95e258a2dc 100644
--- a/docs/howto/deployment/wsgi/index.txt
+++ b/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.
diff --git a/docs/howto/deployment/wsgi/uwsgi.txt b/docs/howto/deployment/wsgi/uwsgi.txt
index 5b40d5f2f7..7ff1cdaaf8 100644
--- a/docs/howto/deployment/wsgi/uwsgi.txt
+++ b/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
 -----------
 
diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
index 37477bb5b0..17c9865138 100644
--- a/docs/ref/signals.txt
+++ b/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:
 
diff --git a/docs/releases/1.5.txt b/docs/releases/1.5.txt
index 3b82e479a1..b0bdfbc879 100644
--- a/docs/releases/1.5.txt
+++ b/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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~