Rails - Jul 2006 - RJS - bug I think - caching in development mode

I''ve got a page that has a <div> on it which is updated via RJS. 
If I add/delete from the <div>, advance to the next page, then use the
Back button to return, the updates do not appear unless I Refresh the page. 
This is in development mode where caching is disabled (I checked development.rb
to be sure).  I''ve tried expiring the page and that doesn''t
help.  Anybody got any idea what''s going on with this?

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060713/406a8124/attachment.html

I see this issue too, but it doesn''t happen in Safari, just Firefox (I
haven''t tested it in IE). It might have something to do with the
browser not using the newly-updated DOM instead of what it got from
the original request.

Does anyone know how to force the browser to show the updated version?
Do we need to force a refresh when the back button is used?

--Scott

On 7/13/06, Bill Walton <bill.walton@charter.net>
wrote:
>
>
> I''ve got a page that has a <div> on it which is updated via
RJS.  If I
> add/delete from the <div>, advance to the next page, then use the
Back
> button to return, the updates do not appear unless I Refresh the page. 
This
> is in development mode where caching is disabled (I checked development.rb
> to be sure).  I''ve tried expiring the page and that
doesn''t help.  Anybody
> got any idea what''s going on with this?
>
> Thanks,
> Bill
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

-- 

--Scott

I was just playing with Backpack and its todo list items to see how
this is handled there, and it seems to have this "bug" too. It seems
to consistently not see the new items in the todo list after a back
button in Firefox. Oddly, where Safari consistently remembers the new
items on my app, Backpack seems less consistent, sometimes it does and
sometimes not. In any case, it does seem to be an issue, but a
browser-dependent one.

Maybe by adding directives to not cache the page, you could guarantee
a refresh (at the expense of losing the snappier UI)?

--Scott

On 7/13/06, Scott Hill <stmpjmpr@gmail.com> wrote:
> I see this issue too, but it doesn''t happen in Safari, just
Firefox (I
> haven''t tested it in IE). It might have something to do with the
> browser not using the newly-updated DOM instead of what it got from
> the original request.
>
> Does anyone know how to force the browser to show the updated version?
> Do we need to force a refresh when the back button is used?
>
> --Scott
>
> On 7/13/06, Bill Walton <bill.walton@charter.net> wrote:
> >
> >
> > I''ve got a page that has a <div> on it which is updated
via RJS.  If I
> > add/delete from the <div>, advance to the next page, then use
the Back
> > button to return, the updates do not appear unless I Refresh the page.
This
> > is in development mode where caching is disabled (I checked
development.rb
> > to be sure).  I''ve tried expiring the page and that
doesn''t help.  Anybody
> > got any idea what''s going on with this?
> >
> > Thanks,
> > Bill
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> >
> >
>
>
> --
>
> --Scott
>

-- 

--Scott

On 7/13/06, Scott Hill <stmpjmpr@gmail.com> wrote:
> I see this issue too, but it doesn''t happen in Safari, just
Firefox (I
> haven''t tested it in IE). It might have something to do with the
> browser not using the newly-updated DOM instead of what it got from
> the original request.
fwiw, the technical reason behind this is that Firefox doesn''t make
another request when you hit back, but simply renders the HTML that it
first downloaded.  It''s similar to performing a lot of DOM-modifying
actions and then viewing the source - you''ll only see the original
HTML.

You could try using no-cache or expires metatags.  I don''t know
offhand how Firefox behaves though.

Pat

Scott Hill wrote:
> In any case, it does seem to be an issue, but a
> browser-dependent one.
I agree that the results differ by browser, but...
> Maybe by adding directives to not cache the page, you could guarantee
> a refresh (at the expense of losing the snappier UI)?
Any ideas what directives I might use?  In development mode caching is 
already turned off in config/development.rb.

According to the W3C''s RFC 2616, if caching is turned off, the client
and
any proxies in between must NOT use the local copy without revalidating the 
content with the server.

WRT it being a browser issue, Firefox does, in fact, check with the server 
to validate it''s copy.  I can tell because it *does* get a new copy of
the
rest of the page.  I''m inclined, at this point, to think that RJS is
not
paying attention to the page''s Cache-Control setting and is marking the
fragments it renders as ''cachable'' when the page it''s
updating is maked ''not
cachable''.  If that''s the case, that''s a bug.  It
could be a serious one,
too, because that could mean that RJS isn''t safe to use in apps that
serve
secure content.

Thanks for your responses!

Best regards,
Bill

I was able to get Firefox to reload the entire page, even the parts rendered 
via RJS, by adding ''no-store'' to the Cache-Control header.  I
did this by
adding a protected method to application.rb and calling it in an 
after_filter in each of the controllers that use RJS templates.  Code below 
for folks in the future.

Thanks again for your responses.

Best regards,
Bill

--- application.rb ---
########################################################
#   NOTE:  the result is sensitive to the case of the parameter.
#                
response.headers["Cache-Control"]="no-store"  -->
Cache-Control: no-store
#                
response.headers["Cache-control"]="no-store"  -->
Cache-Control: no-cache, no-store
#  The presence of no-cache seems to have no effect for Firefox one way or 
the other.  Both work in this case.
########################################################

  protected

  def prevent_caching
    response.headers["Cache-Control"] = "no-store"
  end

---- at the beginning of each controller that utilizes RJS templates -----

  after_filter :prevent_caching