Fixed #28031 -- Removed notes about old uWSGI/sentry versions (refs #20537).

docs/howto/deployment/wsgi/index.txt

@@ -81,10 +81,3 @@ 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`: https://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. 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,15 +34,6 @@ command. For example:
 
 .. _installation procedures: https://uwsgi-docs.readthedocs.io/en/latest/Install.html
 
-.. 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

@@ -531,14 +531,6 @@ Arguments sent with this signal:
 
 Sent when Django finishes delivering an HTTP response 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:
 
 ``sender``