mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-31 09:41:08 +00:00
Code Issues 32 Releases Wiki Activity

[1.5.x] Warned that request_finished isn't sent by some buggy setups.

Browse Source 
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
This commit is contained in:
Jaap Roes
2013-06-03 15:53:04 +02:00
committed by Aymeric Augustin
parent b75f1f3d27
commit 60353458ae
4 changed files with 38 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/howto/deployment/wsgi/index.txt
View File

@@ -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.

9
docs/howto/deployment/wsgi/uwsgi.txt
View File

@@ -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
-----------

21
docs/ref/signals.txt
View File

@@ -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:

10
docs/releases/1.5.txt
View File

@@ -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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~