CODEWITHSUNDEEP
pythondjango
thebjorn
thebjorn

Reputation: 27360

What is the correct ordering of Django middleware?

This page: https://docs.djangoproject.com/en/1.7/ref/middleware/#middleware-ordering has/implies the following ordering (Question #1: Am I correct in assuming the list is in correct order?)

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

while the graphic at https://docs.djangoproject.com/en/dev/topics/http/middleware/#hooks-and-application-order seems to indicate that CommonMiddleware should be before SessionMiddleware:

In Django 1.5 django-admin.py startproject generates (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',
)

while versions starting with 1.6 generate (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',
)

Question #2: Should I change the order in my 1.5 projects so SessionMiddleware is before CommonMiddleware?

Question #3: How will requests be processed differently when switching the order?

Upvotes: 7

Views: 3214

Answers (1)

Anzel
Anzel

Reputation: 20583

FYI, you may be interested in reading Django 1.7 Middleware Ordering. It explains the consequences of the middleware ordering, and I think it still applies on previous Django versions.

Middleware ordering Here are some hints about the ordering of various Django middleware classes:

UpdateCacheMiddleware

Before those that modify the Vary header (SessionMiddleware, GZipMiddleware, LocaleMiddleware).

GZipMiddleware

Before any middleware that may change or use the response body.

After UpdateCacheMiddleware: Modifies Vary header.

ConditionalGetMiddleware

Before CommonMiddleware: uses its Etag header when USE_ETAGS = True.

SessionMiddleware

After UpdateCacheMiddleware: Modifies Vary header.

LocaleMiddleware

One of the topmost, after SessionMiddleware (uses session data) and CacheMiddleware (modifies Vary header).

CommonMiddleware

Before any middleware that may change the response (it calculates ETags).

After GZipMiddleware so it won’t calculate an ETag header on gzipped contents.

Close to the top: it redirects when APPEND_SLASH or PREPEND_WWW are set to True.

Updates (as pointed by OP in comments)

The relevant change seems to be Enabled the locale middleware by default.

In the comments from that commit:

+.. versionchanged:: 1.6 + In previous versions, 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`` after it.

So, in fact the new changes in ordering is to resolve enabling LocaleMiddleWare by default. You shouldn't need to change these orders in previous Django's versions because it's not enabled by default.

Update

LocaleMiddleware has been removed from the project template

Upvotes: 6

Related Questions