Fixed #6527 -- Provided repeatable content access

in HttpResponses instantiated with iterators.
This commit is contained in:
Aymeric Augustin 2012-10-23 22:25:38 +02:00
parent 83041ca802
commit 495a8b8107
5 changed files with 104 additions and 38 deletions

View file

@ -286,6 +286,10 @@ these changes.
* The ``mimetype`` argument to :class:`~django.http.HttpResponse` ``__init__``
will be removed (``content_type`` should be used instead).
* When :class:`~django.http.HttpResponse` is instantiated with an iterator,
or when :attr:`~django.http.HttpResponse.content` is set to an iterator,
that iterator will be immediately consumed.
* The ``AUTH_PROFILE_MODULE`` setting, and the ``get_profile()`` method on
the User model, will be removed.

View file

@ -569,18 +569,25 @@ Passing iterators
Finally, you can pass ``HttpResponse`` an iterator rather than strings. If you
use this technique, the iterator should return strings.
Passing an iterator as content to :class:`HttpResponse` creates a
streaming response if (and only if) no middleware accesses the
:attr:`HttpResponse.content` attribute before the response is returned.
.. versionchanged:: 1.5
Passing an iterator as content to :class:`HttpResponse` creates a
streaming response if (and only if) no middleware accesses the
:attr:`HttpResponse.content` attribute before the response is returned.
This technique is fragile and was deprecated in Django 1.5. If you need the
response to be streamed from the iterator to the client, you should use the
:class:`StreamingHttpResponse` class instead.
If you want to guarantee that your response will stream to the client, you
should use the new :class:`StreamingHttpResponse` class instead.
As of Django 1.7, when :class:`HttpResponse` is instantiated with an
iterator, it will consume it immediately, store the response content as a
string, and discard the iterator.
If an :class:`HttpResponse` instance has been initialized with an iterator as
its content, you can't use it as a file-like object. Doing so will raise an
exception.
.. versionchanged:: 1.5
You can now use :class:`HttpResponse` as a file-like object even if it was
instantiated with an iterator. Django will consume and save the content of
the iterator on first access.
Setting headers
~~~~~~~~~~~~~~~

View file

@ -84,6 +84,8 @@ For one-to-one relationships, both sides can be cached. For many-to-one
relationships, only the single side of the relationship can be cached. This
is particularly helpful in combination with ``prefetch_related``.
.. _explicit-streaming-responses:
Explicit support for streaming responses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -98,7 +100,7 @@ You can now explicitly generate a streaming response with the new
is an iterator.
Since :class:`~django.http.StreamingHttpResponse` does not have a ``content``
attribute, middleware that need access to the response content must test for
attribute, middleware that needs access to the response content must test for
streaming responses and behave accordingly. See :ref:`response-middleware` for
more information.
@ -483,6 +485,30 @@ Features deprecated in 1.5
.. _simplejson-deprecation:
:setting:`AUTH_PROFILE_MODULE`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With the introduction of :ref:`custom User models <auth-custom-user>`, there is
no longer any need for a built-in mechanism to store user profile data.
You can still define user profiles models that have a one-to-one relation with
the User model - in fact, for many applications needing to associate data with
a User account, this will be an appropriate design pattern to follow. However,
the :setting:`AUTH_PROFILE_MODULE` setting, and the
:meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
the user profile model, should not be used any longer.
Streaming behavior of :class:`HttpResponse`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.5 deprecates the ability to stream a response by passing an iterator
to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
:class:`~django.http.StreamingHttpResponse`. See :ref:`explicit-streaming-
responses` above.
In Django 1.7 and above, the iterator will be consumed immediately by
:class:`~django.http.HttpResponse`.
``django.utils.simplejson``
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -497,12 +523,6 @@ incompatibilities between versions of :mod:`simplejson` -- see the
If you rely on features added to :mod:`simplejson` after it became Python's
:mod:`json`, you should import :mod:`simplejson` explicitly.
``itercompat.product``
~~~~~~~~~~~~~~~~~~~~~~
The :func:`~django.utils.itercompat.product` function has been deprecated. Use
the built-in :func:`itertools.product` instead.
``django.utils.encoding.StrAndUnicode``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -510,6 +530,13 @@ The :class:`~django.utils.encoding.StrAndUnicode` mix-in has been deprecated.
Define a ``__str__`` method and apply the
:func:`~django.utils.encoding.python_2_unicode_compatible` decorator instead.
``django.utils.itercompat.product``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :func:`~django.utils.itercompat.product` function has been deprecated. Use
the built-in :func:`itertools.product` instead.
``django.utils.markup``
~~~~~~~~~~~~~~~~~~~~~~~
@ -517,16 +544,3 @@ The markup contrib module has been deprecated and will follow an accelerated
deprecation schedule. Direct use of python markup libraries or 3rd party tag
libraries is preferred to Django maintaining this functionality in the
framework.
:setting:`AUTH_PROFILE_MODULE`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With the introduction of :ref:`custom User models <auth-custom-user>`, there is
no longer any need for a built-in mechanism to store user profile data.
You can still define user profiles models that have a one-to-one relation with
the User model - in fact, for many applications needing to associate data with
a User account, this will be an appropriate design pattern to follow. However,
the :setting:`AUTH_PROFILE_MODULE` setting, and the
:meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
the user profile model, should not be used any longer.