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?
A:
I don't understand why you are looking for a reason not to do something. However your analysis is far from complete: conditional requests / 304 responses can actually make your application go significantly slower than it would if you strip the if-modified-since / if-none-match however they do keep search engines happy and are advantageous with server-server replication (e.g. on CDNs)
C.
symcbean
2010-05-05 13:21:03
This answer isn't very helpful for several reasons: 1) Your second sentence contains several ideas that could be split up into several sentences. 2) Why shouldn't I be looking for a good reason not to do something? 3) You state that 304 responses can make things slower without explaining why. While you mentioned something about not using if-modified-since (not sure how this applies to ETag's) and if-none-match headers, but that's not really much of an explanation. 4) "they do keep search engines happy"? Intriguing, but extremely vague.
allyourcode
2010-05-06 09:28:15