RJS - bug I think - caching in development mode

Rails
#1

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

#2

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. [email protected] wrote:

Bill

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

–

–Scott

#3

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. [email protected] wrote:

On 7/13/06, Bill W. [email protected] wrote:

Bill

–Scott

–

–Scott

#4

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

#5

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

#6

On 7/13/06, Scott H. [email protected] 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