What is the correct order of Django middleware?

Question

This page: https://docs.djangoproject.com/en/1.7/ref/middleware/#middleware-ordering has / implies the following order ( Question No. 1: Do I think the list is in the 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 in https://docs.djangoproject.com/en/dev/topics/http/middleware/#hooks-and-application-order indicates 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: Do I have to reorder in my 1.5 projects so that SessionMiddleware is before CommonMiddleware?

Question No. 3: How will requests be handled differently when switching an order?

Answer 1

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

Ordering middleware Here are some tips on ordering various Django middleware classes:

UpdateCacheMiddleware

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

Gzipmiddleware

Before any middleware that can modify or use the response body.

After UpdateCacheMiddleware: changes the Vary header.

ConditionalGetMiddleware

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

SessionMiddleware

After UpdateCacheMiddleware: changes the Vary header.

Localemiddleware

One of the top ones, after SessionMiddleware (uses session data) and CacheMiddleware (changes the Vary header).

CommonMiddleware

Before any middleware that can change the answer (it calculates ETags).

After GZipMiddleware, therefore, it will not calculate the ETag header on the gzipped content.

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

Updates (as indicated by OP in the comments)

The corresponding change looks like Enabled locale middleware by default .

In the comments from this commit:

+ .. versionchanged :: 1.6 + In previous versions of LocaleMiddleware` wasn't enabled by default. + +Because middleware order matters, you should follow these guidelines: * Make sure it one of the first middlewares installed. * It should come after LocaleMiddleware` wasn't enabled by default. + +Because middleware order matters, you should follow these guidelines: * Make sure it one of the first middlewares installed. * It should come after LocaleMiddleware` wasn't enabled by default. + +Because middleware order matters, you should follow these guidelines: * Make sure it one of the first middlewares installed. * It should come after SessionMiddleware , because LocaleMiddleware makes use of session data. And it should come before 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 needs an activated language in order to resolve the requested URL. * If you use CacheMiddleware , put LocaleMiddleware` after it.

Thus, in fact, a new change in the ordering is to allow local use of LocaleMiddleWare by default. You do not need to change these orders in previous versions of Django , since it is not enabled by default.

Update

LocaleMiddleware been removed from the project template.