It also sets the Cache-control:
must-revalidate flag, which instructs caches (including caching user agents, such as
web browsers) to revalidate the cache against the ETag, using the If-None-Match
header. This ensures that the generated ETags are actually used. Finally, if a response
comes in with an If-None-Match header, and its value is the same as the generated
ETag, the response body is cleared and rendered with a 304 Not Modified status.
The default Rails ETag mechanism works well and is completely transparent, but it
has some drawbacks. The main limitation is that the response body must still be generated
(which often means several trips to the database, template rendering, URI
generation, and, finally, MD5 hashing) before a decision can be made. If the client??™s
version was actually the latest, all of that work is discarded. Therefore, the default
ETag implementation only saves bandwidth, not CPU time or I/O. We must get into
more application-specific caching methods in order to avoid rendering a response
altogether.
RESTful Rails | 221
Custom caching
Making cache control more granular requires coupling the caching a bit more with
the application. Assaf Arkin??™s restfully_yours plugin* provides some helper methods
for RESTful Rails development, primarily in the domain of cache control. It provides
methods to support both conditional GET (which controls caches using If-Modified-
Since and If-None-Match) and conditional PUT (which prevents stale updates using
If-Unmodified-Since and If-Match).
Pages:
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347