32

官方文档有点乱：'before' & 'after' 用于在元组中对 MiddleWare 进行排序，但在某些地方 'before'&'after' 指的是请求-响应阶段。此外，“应该是第一个/最后一个”是混合的，不清楚哪个用作“第一个”。

我确实理解其中的区别。但是对于 Django 的新手来说，这似乎很复杂。

您能否为内置的 MiddleWare 类推荐一些正确的顺序（假设我们启用了所有这些类）并且——最重要的是——解释为什么一个在其他类之前/之后？

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

  1. UpdateCacheMiddleware
    • 在那些修改 'Vary:' 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它不会计算压缩内容的电子标签
    • 靠近顶部：它在APPEND_SLASH或时重定向PREPEND_WWW
  7. CsrfViewMiddleware
    • 在任何假定 CSRF 攻击已被处理的视图中间件之前
  8. AuthenticationMiddleware
    • 之后SessionMiddleware：使用会话存储
  9. MessageMiddleware
    • After SessionMiddleware：可以使用基于Session的存储
  10. XViewMiddleware
  11. TransactionMiddleware
    • 在使用 DB 的 MW 之后：（SessionMiddleware可配置为使用 DB）
    • 全部*CacheMiddleWare不受影响（作为一个例外：使用自己的 DB 游标）
  12. FetchFromCacheMiddleware
    • 在那些修改'Vary：'的那些之后，如果使用它们为缓存哈希键选择一个值
    • 之后AuthenticationMiddleware可以使用CACHE_MIDDLEWARE_ANONYMOUS_ONLY
  13. FlatpageFallbackMiddleware
    • 下：最后的手段
    • 但是，使用 DB 不是问题TransactionMiddleware （是吗？）
  14. RedirectFallbackMiddleware
    • 下：最后的手段
    • 但是，使用 DB 不是问题TransactionMiddleware （是吗？）

（我会将建议添加到此列表中，以便将所有建议收集在一个地方）

4

2 回答 2

4

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

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

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

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

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

于 2011-01-08T04:42:41.463 回答
2

可以节省您的头发的一个技巧是将 TransactionMiddleware 放在列表中的这样一个位置，其中它无法回滚其他中间件提交到数据库的更改，无论视图是否引发异常都应该提交这些更改.

于 2011-03-10T20:21:27.520 回答