Официальная документация немного беспорядочна: "before" и "after" используются для заказа MiddleWare в кортеже, но в некоторых местах "до" & "after" относится к этапам запроса-ответа. Кроме того, "должно быть первым/последним" смешаны, и не понятно, какой из них использовать как "первый".
Я понимаю разницу. Однако, похоже, это сложно для новичков в Django.
Можете ли вы предложить правильный порядок для встроенных классов MiddleWare (при условии, что мы включим их все) и, что самое важное, объясните, ПОЧЕМУ, что один идет до/после других?
вот список, с информацией из документов, которые мне удалось найти:
-
UpdateCacheMiddleware
- Перед тем, которые изменяют "Vary:"
SessionMiddleware
,GZipMiddleware
,LocaleMiddleware
- Перед тем, которые изменяют "Vary:"
-
GZipMiddleware
- Перед любым MW, который может изменить или использовать тело ответа
- После
UpdateCacheMiddleware
: Изменяет параметр "Vary:"
-
ConditionalGetMiddleware
- До
CommonMiddleware
: использует заголовок "Etag:", когдаUSE_ETAGS=True
- До
-
SessionMiddleware
- После
UpdateCacheMiddleware
: Изменяет параметр "Vary:" - До
TransactionMiddleware
: здесь нам не нужны транзакции.
- После
-
LocaleMiddleware
, один из самых верхних, после SessionMiddleware, CacheMiddleware- После
UpdateCacheMiddleware
: Изменяет параметр "Vary:" - После
SessionMiddleware
: использует данные сеанса
- После
-
CommonMiddleware
- Перед любым MW, который может изменить ответ (он вычисляет ETags)
- После
GZipMiddleware
, поэтому он не рассчитает E-Tag на содержимое gzipped - Близко к началу: он перенаправляет, когда
APPEND_SLASH
илиPREPEND_WWW
-
CsrfViewMiddleware
- Перед любым промежуточным программным обеспечением просмотра, предполагающим, что атаки CSRF были обработаны
-
AuthenticationMiddleware
- После
SessionMiddleware
: использует хранилище сеансов
- После
-
MessageMiddleware
- После
SessionMiddleware
: можно использовать хранилище на основе сеанса
- После
-
XViewMiddleware
-
TransactionMiddleware
- После MW, которые используют DB:
SessionMiddleware
(настраивается для использования БД) - Все
*CacheMiddleWare
не затрагиваются (как исключение: использует собственный курсор DB)
- После MW, которые используют DB:
-
FetchFromCacheMiddleware
- После тех, которые изменяют "Vary:" , если они используют их для выбора значения для хэш-ключа кеша
- После
AuthenticationMiddleware
, чтобы можно было использоватьCACHE_MIDDLEWARE_ANONYMOUS_ONLY
-
FlatpageFallbackMiddleware
- Нижняя часть: в крайнем случае
- Использование DB, однако, не является проблемой для
TransactionMiddleware
(да?)
-
RedirectFallbackMiddleware
- Нижняя часть: в крайнем случае
- Использование DB, однако, не является проблемой для
TransactionMiddleware
(да?)
(Я добавлю предложения в этот список, чтобы собрать их все в одном месте)