Практические правила для заказа Django MiddleWare?

Официальная документация немного беспорядочна: "before" и "after" используются для заказа MiddleWare в кортеже, но в некоторых местах "до" & "after" относится к этапам запроса-ответа. Кроме того, "должно быть первым/последним" смешаны, и не понятно, какой из них использовать как "первый".

Я понимаю разницу. Однако, похоже, это сложно для новичков в Django.

Можете ли вы предложить правильный порядок для встроенных классов MiddleWare (при условии, что мы включим их все) и, что самое важное, объясните, ПОЧЕМУ, что один идет до/после других?

вот список, с информацией из документов, которые мне удалось найти:

UpdateCacheMiddleware
- Перед тем, которые изменяют "Vary:" SessionMiddleware, GZipMiddleware, LocaleMiddleware
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)
FetchFromCacheMiddleware
- После тех, которые изменяют "Vary:" , если они используют их для выбора значения для хэш-ключа кеша
- После AuthenticationMiddleware, чтобы можно было использовать CACHE_MIDDLEWARE_ANONYMOUS_ONLY
FlatpageFallbackMiddleware
- Нижняя часть: в крайнем случае
- Использование DB, однако, не является проблемой для TransactionMiddleware (да?)
RedirectFallbackMiddleware
- Нижняя часть: в крайнем случае
- Использование DB, однако, не является проблемой для TransactionMiddleware (да?)

(Я добавлю предложения в этот список, чтобы собрать их все в одном месте)

Ответ 1

Самая сложная часть состоит в том, что вы должны учитывать оба направления одновременно при настройке порядка. Я бы сказал, что недостаток в дизайне и я лично выбрал бы отдельный порядок request и response промежуточного программного обеспечения (так что вам не нужны хаки, такие как FetchFromCacheMiddleware и UpdateCacheMiddleware).

Но... увы, это так прямо сейчас.

В любом случае, идея всего заключается в том, что ваш запрос проходит через список посредников в порядке сверху вниз для process_request и process_view. И он передает ваш ответ через process_response и process_exception в обратном порядке.

С UpdateCacheMiddleware это означает, что перед этим должно появиться любое промежуточное программное обеспечение, которое изменяет заголовки Vary в HTTP-запросе. Если вы измените порядок здесь, то для некоторых пользователей можно будет получить кешированную страницу для другого пользователя.

Как узнать, изменен ли заголовок Vary промежуточным программным обеспечением? Вы можете надеяться, что есть документы, или просто посмотрите на источник. Это обычно совершенно очевидно:)

Ответ 1

Ответ 2