-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jim,
This is a really useful summary of the current state of things, thanks for putting it together. Re the anonymous/authenticated issue, CSRF token, and Google Analytics cookies, it all boils down to the same root issue. And Niran is right, what we currently do re setting Vary: Cookie is what we have to do in order to be correct with respect to HTTP and upstream caches. For instance, we can't just remove Vary: Cookie from unauthenticated responses, because then upstream caches could serve that unauthenticated response to anyone, even if they are actually authenticated. Currently the Django page caching middleware behaves pretty much just like an upstream cache in terms of the Vary header. Apart from the CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting, it just looks at the response, it doesn't make use of any additional "inside information" about what your Django site did to generate that response in order to decide what to cache and how to cache it. This approach is pretty attractive, because it's conceptually simple, consistent with upstream HTTP caching, and conservative (quite unlikely to serve the wrong cached content). It might be possible to make it "smarter" in certain cases, and allow it to cache more aggressively than an upstream cache can. #9249 is one proposal to do this for cookies that aren't used on the server, either via explicit setting or (in a recently-added proposal) via tracking which cookie values are accessed. If we did that, plus special-cased the session cookie if the user is unauthenticated and the session isn't used outside of contrib.auth, I think that could possibly solve the unauthenticated-users and GA issues. However, this (especially the latter) would come with the cost of making the cache middleware implementation more fragile and coupled to other parts of the framework. And it still doesn't help with CSRF, which is a much tougher nut to crack, because every response for pages using CSRF come with a Set-Cookie header and probably with a CSRF token embedded in the response content; and those both mean that response really can't be re-used for anyone else. (Getting rid of the token embedded in the HTML means forms couldn't ever POST without JS help, which is not an option as the documented default approach). You can mark some form-using views that are available to anonymous users as csrf-exempt, which exposes you potentially to CSRF-based spam, but isn't a security issue if you aren't treating authenticated submissions any differently from non-authenticated ones. Generally, I come down on the side of skepticism that introducing these special cases into the cache middleware really buys enough to be worth the added complexity (though I could be convinced that #9249 is worth it). I do think we should improve the cache middleware documentation so its limitations are outlined more clearly upfront, and point people towards existing solutions for caching mostly-but-not-entirely-anonymous pages: edge-side-includes, two-phase-render, and JS/AJAX fetch. #15855, on the other hand, is a bug that really does need to be fixed. I still don't see a better fix than the one I outlined in the ticket description: requiring some middleware to be in MIDDLEWARE_CLASSES for the cache_page decorator to work, and not doing the actual caching until we hit that middleware. Or alternatively, adding an implicit "cache any responses that had cache_page used on them" phase to response processing, after all middleware. I think those are both ugly fixes, though; maybe someone has a better idea. The last time I know of that this was discussed in-depth was in http://groups.google.com/group/django-developers/browse_frm/thread/f96e982254fbe5c3/2b02361fd6e706f4 Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6gxKkACgkQ8W4rlRKtE2dnggCfeNOeAw8g4/Y5Zu6iM73HFK0m V6EAn0mGvzLzOs0daC1UZWQp6hZnxvH8 =La3y -----END PGP SIGNATURE----- -- 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.
