关于Django MiddleWare排序的实用规则？

Question

官方文档有点混乱：“在”之前“和”之后“用于在元组中订购MiddleWare，但在某些地方，”前“和”后“指的是请求响应阶段。此外，“应该是第一/最后”是混合的，并且不清楚哪一个应该用作“第一”。

我明白这区别..。然而，对于Django的新手来说，这似乎很复杂。

您能为内置的MiddleWare类提出一些正确的排序(假设我们启用了所有这些类)，并且--最重要的是--解释为什么在其他类之前/之后？

下面列出了我设法找到的文档的信息：

在修改“Vary：”、“

1. UpdateCacheMiddleware”、“LocaleMiddleware

”之前的

​

在任何MW之前在

1. GZipMiddleware
   • 之前更改或使用响应体
   • 后的UpdateCacheMiddleware：修改UpdateCacheMiddleware

​

1. ConditionalGetMiddleware
   • 先于CommonMiddleware：在USE_ETAGS=True

时使用它的'Etag:‘头

​

修改

1. SessionMiddleware 'Vary:'
2. Before TransactionMiddleware：我们不需要事务here

​

1. LocaleMiddleware，是最顶端之一，在SessionMiddleware之后，CacheMiddleware
   • 在UpdateCacheMiddleware之后:修改'Vary:'
   • After SessionMiddleware：uses data

​

1. CommonMiddleware
   • 在任何可能更改响应(计算ETags)的MW之前，在GZipMiddleware之后计算
   • ，这样就不会在压缩后的contents
   • Close上计算E-标记到顶部:当APPEND_SLASH或PREPEND_WWW

时重定向。

​

在任何假定CSRF攻击已被with处理的视图中间件之前，with

​

1. AuthenticationMiddleware
   • 在SessionMiddleware之后:使用session storage

​

1. MessageMiddleware
   • 在SessionMiddleware之后:可以使用基于会话的storage

​

1. XViewMiddleware
2. TransactionMiddleware
   • 在使用DB：SessionMiddleware (可配置为使用DB )
   • 的MWs之后，All *CacheMiddleWare不受影响(作为一个例外:使用自己的DB
   • )

​

1. FetchFromCacheMiddleware
   • ，在那些修改“value：”之后，如果使用它们来选择缓存hash-key
   • After AuthenticationMiddleware的值，那么就可以使用CACHE_MIDDLEWARE_ANONYMOUS_ONLY

​

1. FlatpageFallbackMiddleware
   • 底部:然而，对于TransactionMiddleware (yes?)

来说，最后一个 DB并不是一个问题。

​

1. RedirectFallbackMiddleware
   • 底部:然而，对于TransactionMiddleware (yes?)

来说，最后一个 DB并不是一个问题。

​

(我将在这份清单中添加建议，将所有建议集中在一个地方)

Answer 1

最困难的部分是，你必须同时考虑两个方向时，制定订单。我会说这是设计中的一个缺陷，我个人会选择一个单独的request和response中间件订单(这样您就不需要像FetchFromCacheMiddleware和UpdateCacheMiddleware这样的黑客了)。

但是..。唉，现在是这边。

无论哪种方式，其思想都是您的请求以自顶向下的顺序传递给process_request和process_view的中间件列表。它以相反的顺序通过process_response和process_exception传递您的响应。

使用UpdateCacheMiddleware，这意味着任何更改HTTP请求中的Vary头的中间件都应该出现在它之前。如果您在这里更改订单，那么某些用户将有可能为其他用户获取缓存的页面。

如何找出中间件是否更改了Vary报头？您可以希望有可用的文档，也可以简单地查看源代码。这通常很明显:)

Answer 2

一个可以节省您的头发的小窍门是将TransactionMiddleware放在列表中的这样一个位置，在这个列表中，它无法回滚由其他中间件提交给数据库的更改，不管视图是否引发异常，这些更改都应该被提交给数据库。