Commit 60353458 authored by Jaap Roes's avatar Jaap Roes Committed by Aymeric Augustin
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 3ce1d303.

Conflicts:
	docs/howto/deployment/wsgi/index.txt
parent b75f1f3d

docs/howto/deployment/wsgi/index.txt

+8 −0
Original line number Diff line number Diff line
@@ -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.

docs/howto/deployment/wsgi/uwsgi.txt

+9 −0
Original line number Diff line number Diff line
@@ -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

-----------

docs/ref/signals.txt

+11 −8
Original line number Diff line number Diff line
@@ -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:

docs/releases/1.5.txt

+9 −1
Original line number Diff line number Diff line
@@ -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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~