Django MiddleWare订购的实用规则？

Question

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

我确实理解了它的不同......然而,对于Django的新手而言似乎很复杂.

你能为内置的MiddleWare课程建议一些正确的顺序(假设我们启用了所有这些课程),并且 - 最重要的是 - 解释为什么在其他课程之前/之后？

这是列表,其中包含我设法找到的文档中的信息:

1. UpdateCacheMiddleware
   • 那些修改"之前有所不同:" SessionMiddleware,GZipMiddleware,LocaleMiddleware
2. GZipMiddleware
   • 在任何可能改变或使用响应机构的MW之前
   • 之后UpdateCacheMiddleware:修改'变化:'
3. ConditionalGetMiddleware
   • 之前CommonMiddleware:使用其'Etag:'标题时USE_ETAGS=True
4. SessionMiddleware
   • 之后UpdateCacheMiddleware:修改'变化:'
   • 之前TransactionMiddleware:我们不需要这里的交易
5. LocaleMiddleware,SessionMiddleware,CacheMiddleware之后的最顶级之一
   • 之后UpdateCacheMiddleware:修改'变化:'
   • 之后SessionMiddleware:使用会话数据
6. CommonMiddleware
   • 在任何可能改变响应的MW之前(它计算ETags)
   • 之后GZipMiddleware,它不会计算gzip压缩内容的电子标签
   • 靠近顶部:当APPEND_SLASH或时它重定向PREPEND_WWW
7. CsrfViewMiddleware
   • 在任何假定已经处理了CSRF攻击的视图中间件之前
8. AuthenticationMiddleware
   • 之后SessionMiddleware:使用会话存储
9. MessageMiddleware
   • 之后SessionMiddleware:可以使用基于会话的存储
10. XViewMiddleware
11. TransactionMiddleware
    • 在使用DB的MW之后:(可SessionMiddleware配置为使用DB)
    • 全部*CacheMiddleWare不受影响(作为例外:使用自己的数据库游标)
12. FetchFromCacheMiddleware
    • 在那些修改'Vary:'之后,如果使用它们来为缓存哈希键选择一个值
    • 之后AuthenticationMiddleware就可以使用了CACHE_MIDDLEWARE_ANONYMOUS_ONLY
13. FlatpageFallbackMiddleware
    • 底部:不得已
    • 然而,使用DB不是问题TransactionMiddleware (是吗？)
14. RedirectFallbackMiddleware
    • 底部:不得已
    • 然而,使用DB不是问题TransactionMiddleware (是吗？)

(我将在此列表中添加建议,以便在一个地方收集所有这些建议)

Answer 1

最困难的部分是在设置顺序时必须同时考虑两个方向。我想说这是设计中的一个缺陷，我个人会选择单独的request中间件response订单（这样你就不需要像FetchFromCacheMiddleware和 那样的黑客攻击UpdateCacheMiddleware）。

但是……唉，现在就是这样了。

无论哪种方式，这一切的想法都是您的请求按自上而下的顺序传递 和 的中间件process_request列表process_view。它会以相反的顺序传递您的process_response响应process_exception。

这意味着UpdateCacheMiddleware任何更改VaryHTTP 请求中标头的中间件都应该位于它之前。如果您在此处更改顺序，则某些用户可能会获得其他用户的缓存页面。

如何知道Vary标头是否被中间件更改了？您可以希望有可用的文档，或者只是查看源代码。这通常是很明显的:)