Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

[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
  • Loading branch information...
commit 60353458ae7105ea943dc425954403c581b05255 1 parent b75f1f3
Jaap Roes authored aaugustin committed
View
8 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.
View
9 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
-----------
View
19 docs/ref/signals.txt
@@ -447,17 +447,20 @@ request_finished
Sent when Django finishes processing an HTTP request.
-.. note::
+.. versionchanged:: 1.5
- 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).
+ 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.
-.. 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:
View
10 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please sign in to comment.
Something went wrong with that request. Please try again.