Hey folks --
As some have pointed out in the past, there are some potential
pitfalls in the current way the middleware API works. As it stands
now, MIDDLEWARE_CLASSES is implemented as a stack: the middleware
bits are called in order on the process_request and process_view
phases, and in reverse order on the process_response and
process_exception phases.
The idea behind this was that if you wanted to do something really
low-level like munging the request/response objects, you'd usually
want to be the first request middleware and the last response
middleware. I really didn't want to have to define an order for both
request and response (let alone all four phases).
With more middleware being written, however, people are running into
problems with middleware ordering. Frankly, I hadn't excepted that
the middleware API would be used that much at all, but it's proven to
be pretty useful. Given that we're trying to nail down all our APIs
for a 1.0 release, I think it's time to make any changes to the
middleware API that we need to make.
As I see it, there are three problems (two major, one minor) with the
current setup:
1. There's no way to set the order of the response middleware without
changing the order of the request middleware. So if you've got a
middleware that needs to be the first on both request and response,
you're screwed.
2. Any of the phases are allowed to return an HttpResponse object
which short-circuits the rest of the middleware phases. This means
that a middleware component that returns a HttpResponse in
process_request will prevent any response middleware from being used.
3. The config directive seems rather verbose
("django.middleware.cache.CacheMiddleware") -- this isn't a big deal,
but if it's fixable, that would be wonderful.
This email has been sitting in my drafts folder for a week while I
try to think of a good, clean fix, and apparently I'm not smart
enough... So, anyone have any ideas?
Jacob
- Middleware API Jacob Kaplan-Moss
-
