The only reason I can think of is that calculating ETag
's might be expensive. If pages change very quickly, the browser's cache is likely to be invalidated by the ETag
. In that case, calculating the ETag
would be a waste of time. On the other hand, a giving a 304
response when possible minimizes the amount of time spent in transmission. What are some good guidelines for when ETag
's are likely to be a net winner when implemented with Django's CommonMiddleware
?
As with any caching mechanism, you will need to evaluate the trade-off between time spent manipulating the cache and bandwidth saved because of it.
As you say, if the response is changing often, ETags may not be very useful. ETags are a method for caching entire responses, so if the response changes often not much is actually being cached. However, I would guess that since ETags are in common use, browser implementations are resonably fast, and Django is probably fast enough too.
Perhaps there are other areas before the response that could benefit from caching with, for example, memcached.
Again, it will be beneficial to try profiling this with your real data rather than generalizing to "do or don't use it."
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With