>Am I missing something? This makes quite a big difference, since you >could end up serving private data to the wrong person if you get it >wrong.
No, I think you got it right. The reverse order of middleware in the response phase does make sense, but it is a bit counter-intuitive at some times ;-) So actually in the list of installed middleware, the cache middleware should come early on to make sure that it comes last in the response phase. You should put all middleware that has to react based on the request before it - like the CommonMiddleware, that does possible redirects based on the missing "/" bit (and does some shortcutting itself). In it's request phase the cache middleware just checks wether the requested page is cached and if it is cached (and shortcuts if it has learned something). It uses a learned cache key for that - that cache key is defined in the response phase based on the Vary headers. So it will only take into account those additions to the Vary header that are already in there - Middleware that's before the CacheMiddleware will run after the CacheMiddleware in response and so it's Vary headers won't be used in the cache key. This should definitely be clarified in the documentation. Actually I think it might even make sense to have an additional setting where you give an explicit order of middleware to use in the response phase - that way you could even have different order in request and response phase. Would be interesting what Adrian and Jacob think about this. It could be implemented in a way that if the user doesn't give an explicit response order, it will just be the reversed list of middleware - that way it's like it is now. But if the user wants control, he can set up a list of response phase handling. The system could even check that both lists are identical in content and only differ in order, to make sure the user doesn't forget a middlware in that list. It would make things much more obvious, I think. bye, Georg
