Sean,

My project is using both the ratings extension and the comments extension,
and I had the same problem with the comments extension.  I set the config
setting that causes comments to be posted to the page's URL (as you
recommended) and while it works great in Safari, it doesn't work in Firefox.
 In Firefox, the user gets an old version of the page without the comment
they have just submitted.

Maybe there's something else I don't have configured right?

Anyhow, for the time being I'm going to stick with my little etag hack.  The
site doesn't perform as well, but given that I don't expect much traffic,
I'll take correct behavior over faster performance.

Myron

On Fri, Dec 4, 2009 at 5:29 AM, Sean Cribbs <seancri...@gmail.com> wrote:

> 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
>
_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to