What is the correct ordering of Django middleware?

Question

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?

Answer 1

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