[2.0.x] Fixed #28786 -- Doc'd middleware ordering considerations due to CommonMiddleware setting Content-Length.
Backport of bc95314ca6
from master
This commit is contained in:
parent
ca0a9c938f
commit
3f372ef9d3
|
@ -488,7 +488,9 @@ Here are some hints about the ordering of various Django middleware classes:
|
|||
|
||||
#. :class:`~django.middleware.common.CommonMiddleware`
|
||||
|
||||
Before any middleware that may change the response (it calculates ``ETags``).
|
||||
Before any middleware that may change the response (it sets the ``ETag`` and
|
||||
``Content-Length`` headers). A middleware that appears before
|
||||
``CommonMiddleware`` and changes the response must reset the headers.
|
||||
|
||||
After ``GZipMiddleware`` so it won't calculate an ``ETag`` header on gzipped
|
||||
contents.
|
||||
|
|
|
@ -730,6 +730,12 @@ Miscellaneous
|
|||
``Content-Length`` header as this is now done by
|
||||
:class:`~django.middleware.common.CommonMiddleware`.
|
||||
|
||||
If you have a middleware that modifies a response's content and appears
|
||||
before ``CommonMiddleware`` in the ``MIDDLEWARE`` or ``MIDDLEWARE_CLASSES``
|
||||
settings, you must reorder your middleware so that responses aren't modified
|
||||
after ``Content-Length`` is set, or have the response modifying middleware
|
||||
reset the ``Content-Length`` header.
|
||||
|
||||
* :meth:`~django.apps.AppConfig.get_model` and
|
||||
:meth:`~django.apps.AppConfig.get_models` now raise
|
||||
:exc:`~django.core.exceptions.AppRegistryNotReady` if they're called before
|
||||
|
|
Loading…
Reference in New Issue