diff --git a/docs/howto/deployment/wsgi/index.txt b/docs/howto/deployment/wsgi/index.txt
index ad32366bf8..17eb53cf0c 100644
--- a/docs/howto/deployment/wsgi/index.txt
+++ b/docs/howto/deployment/wsgi/index.txt
@@ -82,6 +82,14 @@ 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.
+
 Upgrading from Django < 1.4
 ---------------------------
 
diff --git a/docs/howto/deployment/wsgi/uwsgi.txt b/docs/howto/deployment/wsgi/uwsgi.txt
index 22f39342d6..3e9b47e8f9 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 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::
-
-    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 c54373ee41..a1b046776b 100644
--- a/docs/releases/1.5.txt
+++ b/docs/releases/1.5.txt
@@ -440,7 +440,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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~