In 1.10, Django changed the way middleware works. Several of the
built-in methods were coalesced together into a callable that processes
the request, delegates to other middleware, and then processes the
response. In order to distinguish between the invocation methods, they
renamed the setting from MIDDLEWARE_CLASSES to MIDDLEWARE.
For most of our middleware classes, we can just inherit from the new
MiddlewareMixin class. This allows middleware classes to work
correctly no matter which version of Django they're using.
The big wrinkle here was in extension middleware. To start with, I'm
pretty sure that nobody is using it (our documentation claims that the
middleware attribute should be a list of module paths to the
middleware classes to match the setting, but the implementation was
expecting a list of classes themselves). More importantly, the way that
they were processed (instantiating the classes at init time and then
calling the old process_* methods) wouldn't work with new-style
middleware.
I've added some detection to figure out whether each entry in the list
is old- or new-style, and then depending on what the setting is, do the
right thing. We can run old-style middleware with the new setting, but
can't run new-style middleware with the old setting. Appropriate
warnings have been added in these situations. This includes new test
cases to check that the various different combinations run the
middleware as expected.
