Django中间件的正确排序是什么？

Question

此页面：https://docs.djangoproject.com/en/1.7/ref/middleware/#middleware-ordering具有/暗示以下排序（问题＃1：我在假设列表的顺序正确时是否正确？）

1. UpdateCacheMiddleware
2. GZipMiddlewaree
3. ConditionalGetMiddleware
4. SessionMiddleware
5. LocaleMiddleware
6. CommonMiddleware
7. CsrfViewMiddleware
8. AuthenticationMiddleware
9. MessageMiddleware
10. FetchFromCacheMiddleware
11. FlatpageFallbackMiddleware
12. RedirectFallbackMiddleware

而https://docs.djangoproject.com/en/dev/topics/http/middleware/#hooks-and-application-order处的图形似乎表明CommonMiddleware应该在SessionMiddleware之前：



在Django 1.5中django-admin.py startproject生成（https://docs.djangoproject.com/en/1.5/topics/http/middleware/#hooks-and-application-order）

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
)

以1.6开头的版本生成（https://docs.djangoproject.com/en/1.6/topics/http/middleware/#hooks-and-application-order）

MIDDLEWARE_CLASSES = (
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
)

问题2：我应该更改1.5项目中的顺序，以便SessionMiddleware在CommonMiddleware之前吗？

问题3：切换订单时请求的处理方式如何？

Answer 1

仅供参考，您可能有兴趣阅读Django 1.7 Middleware Ordering。 它解释了中间件订购的后果，我认为它仍然适用于以前的Django版本。

  

中间件订购以下是关于各种订购的一些提示   Django中间件类：

     

UpdateCacheMiddleware

     

在那些修改Vary头之前（SessionMiddleware，   GZipMiddleware，LocaleMiddleware）。

     

GZipMiddleware

     

在任何可能改变或使用响应主体的中间件之前。

     

在UpdateCacheMiddleware之后：修改Vary标头。

     

ConditionalGetMiddleware

     

在CommonMiddleware之前：当USE_ETAGS = True时使用其Etag标题。

     

SessionMiddleware

     

在UpdateCacheMiddleware之后：修改Vary标头。

     

LocaleMiddleware

     

SessionMiddleware（使用会话数据）之后的最顶层之一   CacheMiddleware（修改Vary标头）。

     

CommonMiddleware

     

在任何可能改变响应的中间件之前（它计算   ETag的）。

     

在GZipMiddleware之后，它不会在gzip上计算ETag标头   内容。

     

靠近顶部：它在APPEND_SLASH或PREPEND_WWW时重定向   设为True。

更新（由评论中的OP指出）

相关更改似乎是Enabled the locale middleware by default。

在该提交的评论中：

  

+ .. versionchanged :: 1.6   +在以前的版本中，LocaleMiddleware` wasn't enabled by default. + +Because middleware order matters, you should follow these guidelines: * Make sure it's one of the first middlewares installed. * It should come after SessionMiddleware , because LocaleMiddleware makes use of session data. And it should come before CommonMiddleware because CommonMiddleware needs an activated language in order to resolve the requested URL. * If you use CacheMiddleware , put LocaleMiddleware``之后。

因此，事实上，排序的新变化是默认情况下解决启用LocaleMiddleWare的问题。您不应该在之前的Django版本中更改这些订单，因为它默认情况下未启用。

更新

LocaleMiddleware已removed from the project template