Georg, Thank you for comprehensive answers. I think the part about interaction between different types of middleware should go directly to Django's documentation.
Thanks, Eugene "hugo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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 > >
