Rails%203%20In%20Action

Page and action caching
To make the show action in TicketsController conditionally send back the 304
Not Modified, put this at the bottom of the show method in app/controllers/
tickets_controller.rb:
fresh_when :last_modified => @ticket.updated_at,
:etag => @ticket.to_s + current_user.id.to_s
The last_modified option here sends back another header to the client: the Last-
Modified header. This header is used by a browser to detect when the page was last
updated, which provides a near-identical purpose to an ETag. A browser sends an If-
Modified-Since header that contains the last Last-Modified time. If the server sees
that the Last-Modified time is later than the If-Modified-Since, it will send a new
copy of the page. Otherwise, it will send a 304 Not Modified header.
The :etag option tells fresh_when to generate a new ETag for the resource. Until
this resource changes, the ETag generated will be the same for each user. This
wouldn’t be the case if you didn’t pass through the current_user.id.to_s to the
ETag, but only for two user accounts accessed on the same computer. By using the
current_user’s id attribute to seed the etag option, the tag will be different between
users. How this ETag is generated differs from implementation to implementation; in
Rails it’s an MD5 hash, which is guaranteed uniqueness.
Even though these two options are nearly identical, some browsers may support
one or the other. It’s more of a way to cover your bases to pass through both headers,
and it’s a worthwhile thing to cover.
You can see this in action now if you attempt to visit a ticket’s page. Your first
request will have a final line that says something like this:
Completed 200 OK in 486ms (Views: 200.4ms | ActiveRecord: 5.6ms)
In this instance, the views have been rendered and the entire procedure has taken
486ms. Rather than refreshing the page (because in some browsers, this triggers them
to not send the If-Modified-Since or If-None-Match headers), you’ll go back to the
project’s page and then click back on the same ticket again. This time in the server
output you’ll see this output:
Completed 304 Not Modified in 267ms
The server has sent back a 304 Not Modified response in a slightly quicker time than
your original request, mainly because it didn’t have to re-render the views for the
application and send back all that HTML.
This is another way to ease the load on your server, by getting the browser to deal
with the page caching and serving, rather than the server.
That wraps up this section. You’ve made a small change here you should probably
commit. You can do that by typing these commands into the terminal:
git add .
git commit -m "Add ETag and Last-Modified
support to ticket show page"
459