应用错误收集

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

我确实理解其中的差异......然而，对于Django中的新手而言似乎很复杂。

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

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

UpdateCacheMiddleware
- 在修改'Vary：'SessionMiddleware，GZipMiddleware，LocaleMiddleware
GZipMiddleware
- 在任何可能改变或使用响应主体的MW之前
- UpdateCacheMiddleware之后：修改'Vary：'
ConditionalGetMiddleware
- CommonMiddleware之前：在USE_ETAGS=True
SessionMiddleware
- UpdateCacheMiddleware之后：修改'Vary：'
- 在TransactionMiddleware之前：我们不需要此处的交易
LocaleMiddleware，是SessionMiddleware，CacheMiddleware之后的最顶级之一
- UpdateCacheMiddleware之后：修改'Vary：'
- SessionMiddleware之后：使用会话数据
CommonMiddleware
- 在任何可能改变响应的MW之前（它计算ETags）
- GZipMiddleware之后，因此无法计算gzip压缩内容的电子标记
- 靠近顶部：它会在APPEND_SLASH或PREPEND_WWW
CsrfViewMiddleware
- 在假定已经处理了CSRF攻击的任何视图中间件之前
AuthenticationMiddleware
- SessionMiddleware之后：使用会话存储
MessageMiddleware
- SessionMiddleware之后：可以使用基于会话的存储
XViewMiddleware
TransactionMiddleware
- 使用DB的MW：SessionMiddleware（可配置为使用DB）
- 所有*CacheMiddleWare都不受影响（例外：使用自己的数据库游标）
FetchFromCacheMiddleware
- 那些修改'Vary：'后，如果使用它们为缓存哈希键选择一个值
- AuthenticationMiddleware之后，可以使用CACHE_MIDDLEWARE_ANONYMOUS_ONLY
FlatpageFallbackMiddleware
- 底部：最后的手段
- 然而，对TransactionMiddleware 使用数据库不是问题（是吗？）
RedirectFallbackMiddleware
- 底部：最后的手段
- 然而，对TransactionMiddleware 使用数据库不是问题（是吗？）

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

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

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

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

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

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

Django MiddleWare订购的实用规则？

2 个答案: