Django MiddleWare订购的实用规则？ [英] Practical rules for Django MiddleWare ordering?

问题描述

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

我明白了区别..但是似乎对于Django中的新手来说，这是复杂的。

你可以为内建的MiddleWare类提供一些正确的排序（假设我们启用了所有这些），最重要的是 - 解释为什么/其他的？

这里是列表，从docs的信息我设法找到：

1. UpdateCacheMiddleware
   
   
   
   • 在修改'Vary：' SessionMiddleware ， GZipMiddleware ， LocaleMiddleware
   
   
   li>
   
2. GZipMiddleware
   
   
   
   • 在任何可能更改或使用响应正文的MW之前li>
     
   • UpdateCacheMiddleware ：修改'Vary：'
   
   


3. ConditionalGetMiddleware
   
   
   
   • 之前 C ommonMiddleware ：当 USE_ETAGS = True
   
   
$时，使用其Etag：标题b $ b
4. SessionMiddleware
   
   
   
   • UpdateCacheMiddleware 修改'Vary：'
   
   
   • 在 TransactionMiddleware 之前：我们不需要这里的交易
   
   


5. LocaleMiddleware ，SessionMiddleware中最高的一个，CacheMiddleware
   
   
   
   • UpdateCacheMiddleware ：修改'Vary：'
   
   
   • SessionMiddleware ：使用会话数据
   
   


6. CommonMiddleware
   
   
   <在任何可能更改响应的MW（计算ETag）之前
   
   • 在 GZipMiddleware 之后，所以不会计算E-关于gzip压缩内容的标签
   
   
   • 接近顶端：当 APPEND_SLASH 或 PREPEND_WWW
   
   


7. CsrfViewMiddleware
   
   
   
   • 在假设CSRF攻击的任何视图中间件被处理之前，都已处理
   
   


8. 认证中间件
   
   
   
   • SessionMiddleware ：使用会话存储
   
   


9. MessageMiddleware
   
   
   
   • SessionMiddleware ：可以使用基于会话的存储
   
   


10. XViewMiddleware


11. TransactionMiddleware
    
    
    
    • 之后使用DB的MW： SessionMiddleware （可配置为使用DB）
    
    
    • 全部 * CacheMiddleWare 不受影响（作为例外：使用自己的DB游标）
    
    


12. FetchFromCacheMiddleware
    
    
    
    • 在那些修改Vary：之后，如果使用它们为缓存哈希键选择一个值
    
    
    • 之后 AuthenticationMiddleware 所以可以使用 CACHE_MIDDLEWARE_ANONYMOUS_ON LY
    
    


13. FlatpageFallbackMiddleware
    
    
    
    • 底部：最后的手段
    
    
    • 使用数据库，但是，对于 TransactionMiddleware >（是？）
    
    


14. RedirectFallbackMiddleware
    
    
    
    • 底部：最后的手段
    
    
    • 使用数据库，但是，对于 TransactionMiddleware < （yes？）
    
    

（我会添加建议在这个列表中收集所有这些在一个地方）

解决方案

最困难的部分是你必须考虑两个方向同时设置订单。我会说这是设计的一个缺陷，我个人会选择一个单独的请求和响应中间件顺序您不需要像 FetchFromCacheMiddleware 和 UpdateCacheMiddleware ）之类的黑客。

无论哪种方式，这一切的想法是，您的请求通过顶部的中间件列表 process_request 和 process_view 的下订单。并通过 process_response 和 process_exception 以相反的顺序传递您的回复。

使用 UpdateCacheMiddleware 这意味着任何改变HTTP请求中的 Vary 头文件的中间件应该在它之前。如果您更改这里的顺序，某些用户可能会为某些其他用户获取缓存页面。

如何查看变量头被中间件更改？你可以希望有文档可用，或者只是看源。通常很明显：）

The official documentation is a bit messy: 'before' & 'after' are used for ordering MiddleWare in a tuple, but in some places 'before'&'after' refers to request-response phases. Also, 'should be first/last' are mixed and it's not clear which one to use as 'first'.

I do understand the difference.. however it seems to complicated for a newbie in Django.

Can you suggest some correct ordering for builtin MiddleWare classes (assuming we enable all of them) and — most importantly — explain WHY one goes before/after other ones?

here's the list, with the info from docs I managed to find:

1. UpdateCacheMiddleware
   • Before those that modify 'Vary:' SessionMiddleware, GZipMiddleware, LocaleMiddleware
2. GZipMiddleware
   • Before any MW that may change or use the response body
   • After UpdateCacheMiddleware: Modifies 'Vary:'
3. ConditionalGetMiddleware
   • Before CommonMiddleware: uses its 'Etag:' header when USE_ETAGS=True
4. SessionMiddleware
   • After UpdateCacheMiddleware: Modifies 'Vary:'
   • Before TransactionMiddleware: we don't need transactions here
5. LocaleMiddleware, One of the topmost, after SessionMiddleware, CacheMiddleware
   • After UpdateCacheMiddleware: Modifies 'Vary:'
   • After SessionMiddleware: uses session data
6. CommonMiddleware
   • Before any MW that may change the response (it calculates ETags)
   • After GZipMiddleware so it won't calculate an E-Tag on gzipped contents
   • Close to the top: it redirects when APPEND_SLASH or PREPEND_WWW
7. CsrfViewMiddleware
   • Before any view middleware that assumes that CSRF attacks have been dealt with
8. AuthenticationMiddleware
   • After SessionMiddleware: uses session storage
9. MessageMiddleware
   • After SessionMiddleware: can use Session-based storage
10. XViewMiddleware
11. TransactionMiddleware
    • After MWs that use DB: SessionMiddleware (configurable to use DB)
    • All *CacheMiddleWare is not affected (as an exception: uses own DB cursor)
12. FetchFromCacheMiddleware
    • After those those that modify 'Vary:' if uses them to pick a value for cache hash-key
    • After AuthenticationMiddleware so it's possible to use CACHE_MIDDLEWARE_ANONYMOUS_ONLY
13. FlatpageFallbackMiddleware
    • Bottom: last resort
    • Uses DB, however, is not a problem for TransactionMiddleware (yes?)
14. RedirectFallbackMiddleware
    • Bottom: last resort
    • Uses DB, however, is not a problem for TransactionMiddleware (yes?)

(I will add suggestions to this list to collect all of them in one place)

解决方案

The most difficult part is that you have to consider both directions at the same time when setting the order. I would say that's a flaw in the design and I personally would opt for a separate request and response middleware order (so you wouldn't need hacks like FetchFromCacheMiddleware and UpdateCacheMiddleware).

But... alas, it's this way right now.

Either way, the idea of it all is that your request passes through the list of middlewares in top-down order for process_request and process_view. And it passes your response through process_response and process_exception in reverse order.

With UpdateCacheMiddleware this means that any middleware that changes the Vary headers in the HTTP request should come before it. If you change the order here than it would be possible for some user to get a cached page for some other user.

How can you find out if the Vary header is changed by a middleware? You can either hope that there are docs available, or simply look at the source. It's usually quite obvious :)

这篇关于Django MiddleWare订购的实用规则？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！