The thing that is kind of unintuitive about HTTP caching is the duality of it - both client and server are responsible. This ultimately makes it very scalable, but (anti-?)patterns that we've grown accustomed to become difficult or confusing at best.
Without knowing the specifics of how the ratings extension works, I can tell you one way that you can invalidate the cache correctly: POST to the page that needs to be refreshed, and return the proper status code and headers. In this case, both the cache and the client will recognize that the old version is invalid, and since it's a POST request, the cache won't store the result. This has worked very well in the comments extension, for example (see also: http://github.com/seancribbs/radiant-comments/blob/master/lib/comment_page_extensions.rb). Sean Myron Marston wrote: > I found a solution to this today. I wanted to update the list in case > anyone else has this problem and also to get feedback. I'm sure my solution > can be improved. > > The basic problem I ran into is that the Radiant cache isn't designed with > regularly changing content (such as page ratings and comments) in mind. It > sets the cache headers in the set_cache_control method: > > http://github.com/radiant/radiant/blob/b912a4e622fec974f7ae2d5e0acad1ad25fd06f8/app/controllers/site_controller.rb#L31-38 > > This works great for static content such as radiant pages...if an admin > changes the page, the user may still see the old version for up to the 5 > minute cache timeout, and that's not really that big of a deal. But it > breaks down when the user _immediately_ needs a fresh version of the page. > When they rate a page or add a comment (I'm using both the ratings and > comments extensions), its a bad user experience if their rating or new > comment doesn't show up--it makes it appear as though it didn't work, and > many users will re-submit their comment, leading to duplicates. > > The solution I found is to use the no-cache header, which, contrary to how > it sounds, does allow a browser to cache a page, but instructs it to > revalidate it with the server every time. (see > http://www.mnot.net/cache_docs/#CACHE-CONTROL for more details). Then I use > an ETag so a 304 Not Modified response is sent except when the page has > changed. > > Here's the code: > > http://gist.github.com/d641725a48e0bf0dd5a8 > > I'm just getting my feet wet with this HTTP caching stuff for the first > time, so it's quite likely this is not an optimal solution, but it's working > for me. I'd welcome feedback if anyone has any suggestions for > improvements. > > It strikes me that this is really something that the comments and ratings > extensions should be handling, but Radiant doesn't provide hooks to make > that easy. Is that on the development roadmap? > > Myron > > On Mon, Nov 30, 2009 at 9:24 AM, Myron Marston <myron.mars...@gmail.com>wrote: > > >> I'm using (and improving) the ratings extension for use in my radiant 0.8.1 >> app. It works well except for a weird caching issue that I haven't been >> able to solve yet. >> >> When a user rates a page, the radiant cache is cleared, so that when they >> are redirected to the page, they get a fresh version of it that includes the >> new rating average. On safari, this works as expected. On firefox, I >> continue to get the old version of the page. I have to manually refresh the >> page to force it to update the rating. >> >> I've investigated it a bit, and discovered that the cached entity and meta >> files are indeed being cleared at the right time. My server logs show that >> when I rate a page using safari, it redirects to the page, and my server >> logs show a hit to SiteController#show_page, indicating that a fresh version >> of the page is being generated. When I do this on firefox, it redirects, >> but there is not a hit to SiteController#show_page. I just see a cached >> version of the page. >> >> So, it appears to me that the cache is being properly cleared on the >> server, but Firefox is continuing to display a version of the page that is >> has cached on the browser. My best guess is that there is some issue with >> the HTTP cache headers that causes Firefox to continue to display it's >> cached page. I haven't dealt with HTTP cache headers before, so I'm not >> really sure how to go about troubleshooting this. >> >> Any suggestions? >> >> Thanks, >> Myron >> >> > _______________________________________________ > Radiant mailing list > Post: Radiant@radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > _______________________________________________ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
