On Sat, 5 Nov 2005 14:31:30 +0100 Sune Kirkeby wrote: > On 11/5/05, hugo <[EMAIL PROTECTED]> wrote: > > I think the reversed order is just counter-intuitive - you just > > don't think about it when adding middleware and talking about > > middleware. > > It's perfecetly obvious to me. I think of it like a normal call-stack; > the request walks down the middleware-stack, the response > walks back up. > > > I think at least an optional way to explicitely specify the order > > would be nice. > > It might be; but you still haven't given an example where you > actually need it. All you have shown is a need for documenting > the way things work.
I agree that functionality shouldn't be added until we have a use case, and the concept of walking up and down the stack helps. It's not quite that simple though - if one of the middleware returns a response during process_request, the other process_request middleware are skipped. But all the process_response middleware will still be called. (I'm getting this from reading handlers/base.py and handlers/modpython.py) Doesn't that add complications for CacheMiddleware? That will cache a version that's been processed by all the response middleware (since it comes high in the list). When you get a cache hit, it returns that response right away in process_request and so all the other middleware and the view itself are skipped. But that response will then go through all the other process_response middleware. If one of them changes the response content e.g. adds 'foo' at the end of each paragraph, then the second time you get it, it will have foo added twice. Which is exactly what happens. (test this without GZip middleware, since that will stop you doing a search and replace on the contents of the response). So I guess there is a use case (and not an entirely silly one - my CsrfMiddleware inserts some HTML into the response, which is now inserted n times). Solutions: 1) allow different ordering for request and response middleware 2) call this a bug in the CacheMiddleware, and make process_response return the one it got out of the cache, not "cache plus middleware" 3) implement the stack of middleware as you described it, which would solve this problem, but I don't know if it might introduce some others. Regards, Luke -- "I regret I wasn't born with opposable toes." (Calvin and Hobbes) Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
