Hi, >1) If I want to use all 3 cache middlewares + session middleware, what is >the correct order now? Is this stack correct:
They can have allmost any order you like, but you have to make sure that the cache middleware is after all middlwares that might change content depending on headers - for example the SessionMiddleware needs to come first. I would put them in in the following order: CommonMiddleware (handles the / and stuff and so does redirects) SessionMiddleware CacheMiddleware ConditionalGetMiddleware GZipMiddleware That way the / handling (redirecting to the / URL if the / is missing) is done first - it's redirecting and so doesn't need any of the other middlewares. Session are handled early on, because some other middleware or the view might depend on it - I think that one should go in as early as possible (for example the i18n middleware will make use of sessions if the middleware is loaded after the SessionMiddleware). Then the caching takes place. I moved the ConditionalGetMiddleware after it, because it depends on headers set in the CacheMiddleware - and using it before the CacheMiddleware will lead to problems, as those headers might not be set. The GZipMiddleware is last and after the cache, because it doesn't really change the content based on headers, it just changes the encoding - so the cache can merrily carry the uncompressed content and that way the cache _only_ will contain uncompressed content. If you have large pages that need to be compressed and so the recompressing takes too much resources, you might want to move it before the CacheMiddleware, as then the cache will store both compressed (for users that request it) and uncompressed pages. >2) If I want to use GZipMiddleware, do I have to specify that my response >depends on presence of 'gzip' in HTTP_ACCEPT_ENCODING? Is it done >automatically? If not, how to specify it? Yes, if you use the GZipMiddleware, pages are compressed if gzip is in the Accept-Encoding header of the request. >3) Do I have to define CACHE_MIDDLEWARE_GZIP? Or is it obsolete now? It is obsolete, now. If you don't want GZipping stuff, just don't load the middleare. >4) Is it possible to use GZipMiddleware without cache? Yes, of course. Every middleware can be used alone from the others. Just use the middleware you need, if you just need compression, just use the GZipMiddleware alone. Even the ConditionalGetMiddleware - but that one needs some headers to be present, so it might not work as good as you would like it without the CacheMiddleware. The reason being that without the CacheMiddleware, the view will allways have to run fully to produce a response and only then the ConditionalGetMiddleware can kick in (it needs the ETag or Last-Modified headers). So if you use it alone without the Cache, the view will still be run, only the transfer is reduced (but that might be usefull, too - for example in tight tranfer volume situations). All middlewares that produce/change the response based on headers will add those headers to the Vary resonse header. That way another cache in front of the project (like a transparent proxy or the proxy of the user) will handle caching correctly. So using the GZipMiddleware alone will make other proxies store pages in the cache based on the URI and the Accept-Encoding header. Using the SessionMiddleware will add the Cookie to the list of headers to base storage on. BTW: Django authentication is cookie based, so if your pages are different for each user (and different for anonymous from logged in users), you might want to use the @vary_on_cookie decorator on those views that are different per user to make sure that those views are cached based on the cookie header. Of course this manual decorating only needs to take place when you don't use the SessionMiddleware, because that alrady adds Cookie to the list of Vary headers. bye, Georg
