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

Question

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

1. UpdateCacheMiddleware
2. GZipMiddlewaree
3. 有条件的GetMiddleware
4. 会话中间件
5. Lo​​caleMiddleware
6. 通用中间件
7. CsrfViewMiddleware
8. 身份验证中间件
9. 消息中间件
10. FetchFromCacheMiddleware
11. FlatpageFallbackMiddleware
12. 重定向FallbackMiddleware

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）。

GZip 中间件

在任何可能更改或使用响应正文的中间件之前。

UpdateCacheMiddleware 之后：修改 Vary 标头。

条件获取中间件

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

会话中间件

UpdateCacheMiddleware 之后：修改 Vary 标头。

LocaleMiddleware

在 SessionMiddleware（使用会话数据）和 CacheMiddleware（修改 Vary 标头）。

通用中间件

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

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

接近顶部：当 APPEND_SLASH 或 PREPEND_WWW 时重定向 设置为 True。

更新（由 OP 在 cmets 中指出）

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

在该提交的 cmets 中：

+.. 版本更改:: 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 afterSessionMiddleware, becauseLocaleMiddlewaremakes use of session data. And it should come beforeCommonMiddlewarebecauseCommonMiddlewareneeds an activated language in order to resolve the requested URL. * If you useCacheMiddleware, putLocaleMiddleware``之后。

所以，实际上排序的新变化是解决默认启用 LocaleMiddleWare 的问题。在以前的Django 的版本中，您不需要更改这些顺序，因为默认情况下未启用。

更新

LocaleMiddleware 一直是removed from the project template