django - 添加 Django 缓存中间件的正确顺序是什么？

Question

我正在尝试向我的 Django 项目添加缓存，但我无法理解关于 middleware ordering 的文档.考虑以下 MIDDLEWARE 列表，它大部分是默认的:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    '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',
    'simple_history.middleware.HistoryRequestMiddleware'
]

如果我理解 this piece of documentation正确地，我应该将三个新条目添加到 MIDDLEWARE 列表中。我的案例是否有不止一种正确的排序？

Answer 1

默认startproject middleware是:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    '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',
]

三个per-site cache middleware给出如下:

MIDDLEWARE = [
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
]

当我们讨论缓存时，还有 ConditionalGetMiddleware这与 conditional view processing 有关:

MIDDLEWARE = [
    'django.middleware.http.ConditionalGetMiddleware'
]

那么问题来了，proper order 是什么？将所有这些组合成一个 MIDDLEWARE 列表？ Django 文档给出了两个特定于缓存的规则:

• UpdateCacheMiddleware 必须之前“任何其他可能向 Vary header 添加内容的中间件”(和 SessionMiddleware, GZipMiddleware, LocaleMiddleware 做)
• FetchFromCacheMiddleware 需要在之后 变化Vary 的中间件运行

虽然如果您有额外的自定义内容可能会更微妙，但基于默认设置的最自然的方法是将所有其他中间件放在缓存中。但是我们将 SecurityMiddleware 放在最前面，因为它只是检查/重定向一些可以通过某些东西更好地完成的东西 [例如nginx] 包装 Django 本身。

CommonMiddleware 应该已经包含在 startproject 列表中的正确位置，所以这很容易。

ConditionalGetMiddleware 比较狡猾； Middleware ordering 的单独部分提示说它是“在 GZipMiddleware [...] 之后”，但总的来说是“在任何可能改变响应的中间件之前”，这有点奇怪，但无论如何......。 (显然 GZip 中间件是 discouraged/problematic。)

最后我得到的是:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.gzip.GZipMiddleware',   # Caution: BREACH attack?
    'django.middleware.http.ConditionalGetMiddleware',
    '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',
    'django.middleware.cache.FetchFromCacheMiddleware',
]

请注意，至少有一个 odd interaction ConditionalGetMiddleware 和 UpdateCacheMiddleware 之间，因为如果/当渲染被 304 响应替换时，前者可能会阻止后者实际缓存渲染。

所以也许更好的是:

MIDDLEWARE = [
    'django.middleware.http.ConditionalGetMiddleware',
    'django.middleware.cache.UpdateCacheMiddleware',
    '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',
    'django.middleware.cache.FetchFromCacheMiddleware',
]

…避免使用 Gzip 并在 HTTP 服务器层处理 HTTPS/HSTS 内容。