On Oct 20, 2011, at 10:26 AM, Niran Babalola wrote: > This problem is inherent to page caching. Workarounds to avoid varying > by cookie for anonymous users are conceptually incorrect. If a single > URL can give different responses depending on who's viewing it, then > it varies by cookie. Preventing CSRF is inherently session-variable as > well. Loading the token via a separate AJAX call is possible, but > there are simpler solutions.
You may in fact be correct, but I'm not convinced by what you're saying here (not that there is any onus on you to convince me of anything of course). I"m suggesting that all anonymous users *could* receive an identical page from the server, theoretically, since the same URL does *not* need to return a different response depending on which (anonymous) user is viewing it. CSRF is obviously a trickier problem, and it's not really worth solving the anonymous user problem if CSRF isn't solved as well. But if both problems were somehow solvable, then we're in a position where per-site cache would be viable for many common scenarios such as the one I described in my original post. If these two problems are in fact unsolvable or not worth solving because simpler alternatives exist, that's fine and understandable. Perhaps per-site/per-view caching are indeed exceptionally limited tools that are beneficial in a very limited number of use cases, and perhaps the "solution" here is tidying up the outstanding bugs and perhaps clarifying the documentation as needed to make the limitations more explicit. > > If you want to cache pages with small portions that vary by user, then > you want edge site includes and something like Varnish to process > them. If you want a much slower, pure-python solution that doesn't > require a separate service running somewhere, then you want > armstrong.esi[1]. Thanks. This post wasn't really about what *I* need btw; I can definitely sort out my caching strategies in other areas as I need to. The post only relates to "me" because I sat down yesterday and said, "Gee, I wonder if I could make use of Django's per-site caching feature for this project I'm working on." I turned it "on" to test it out and then spent the next 6 hours delving into the source code, IRC, ticket tracker, Google etc. to figure out why it wasn't working at all and why @cache_page was, and then after finally sorting it out and grokking all of the moving parts etc, realizing that there was extraordinarily limited value in a per-site/view caching strategy that caches per unique visitor, which is pretty much unavoidable for most common usage patterns. So yeah, maybe it's me and I'm looking at things the wrong way, but needless to say it wasn't a particularly pleasant or worthwhile experience. Not looking for pity btw, but just wondering what I/we can or should do to make it better. Jim -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
