# RJS - bug I think - caching in development mode **URL:** \ **Category:** Rails\ **Created:** [July 13, 2006, 3:30pm UTC](https://www.ruby-forum.com/t/rjs-bug-i-think-caching-in-development-mode/98259 "2006-07-13T15:30:56Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 13, 2006, 3:30pm UTC](https://www.ruby-forum.com/t/rjs-bug-i-think-caching-in-development-mode/98259/1 "2006-07-13T15:30:56Z")
I’ve got a page that has a on it which is updated via RJS. If I add/delete from the , 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 ---
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 13, 2006, 3:46pm UTC](https://www.ruby-forum.com/t/rjs-bug-i-think-caching-in-development-mode/98259/2 "2006-07-13T15:46:31Z")
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 W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Bill > > * * * > > Rails mailing list > removed\_email\_address@domain.invalid > [http://lists.rubyonrails.org/mailman/listinfo/rails](http://lists.rubyonrails.org/mailman/listinfo/rails) – –Scott ---
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 13, 2006, 4:09pm UTC](https://www.ruby-forum.com/t/rjs-bug-i-think-caching-in-development-mode/98259/3 "2006-07-13T16:09:53Z")
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 H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On 7/13/06, Bill W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > Bill > > –Scott – –Scott ---
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 13, 2006, 4:57pm UTC](https://www.ruby-forum.com/t/rjs-bug-i-think-caching-in-development-mode/98259/4 "2006-07-13T16:57:24Z")
Scott H. 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 ---
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 13, 2006, 10:14pm UTC](https://www.ruby-forum.com/t/rjs-bug-i-think-caching-in-development-mode/98259/5 "2006-07-13T22:14:32Z")
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 ---
**Author:** ![wpwood](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/d6d6ee/32.png) [@wpwood](https://www.ruby-forum.com/u/wpwood)\ **Post date:** [July 13, 2006, 4:16pm UTC](https://www.ruby-forum.com/t/rjs-bug-i-think-caching-in-development-mode/98259/6 "2006-07-13T16:16:34Z")
On 7/13/06, Scott H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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