How does Rails generate ETags by default? I’ve got
config.action_controller.
perform_caching set to true in production so that I can use page-level
caching in a few specific places, but it seems that Rails is
automatically
setting ETags on all responses even though I’m not using fresh_when or
the stale? helpers in any of my actions. How is Rails deciding to do
this
and how do I disable it without killing page caching?
On Tuesday, October 2, 2012 9:50:39 PM UTC+1, jcoleman wrote:
How does Rails generate ETags by default? I’ve got config.
action_controller.perform_caching set to true in production so that I can
use page-level caching in a few specific places, but it seems that Rails is
automatically setting ETags on all responses even though I’m not using
fresh_when or the stale? helpers in any of my actions. How is Rails
deciding to do this and how do I disable it without killing page caching?
The Rack::Etag middleware does this, using an MD5 of the response body
as
the actual etag. I would have thought that removing Rack::ETag from the
middleware stack would hobble this.
Fred
Is there a way to disable certain middleware based on the route? Part of
my
application is an API that shouldn’t really ever be sending 304’s while
I’m
fine with the web application doing that. It seems like removing
Rack::ConditionalGet should eliminate the setting of the 304 when the
ETags
match, but I don’t see a way in the documentation to remove middleware
non-globally.
I ended up inserting my own middleware before Rack::Cache (which was
actually causing the issue–I’d even tried removing Rack::ConditonalGet
and
the issue was still happening) that removes the If-None-Matches and
If-Modified-Since headers on the matching requests.
Thanks for the help!
On Wednesday, October 3, 2012 2:11:33 PM UTC+1, jcoleman wrote:
Is there a way to disable certain middleware based on the route? Part of
my application is an API that shouldn’t really ever be sending 304’s while
I’m fine with the web application doing that. It seems like removing
Rack::ConditionalGet should eliminate the setting of the 304 when the ETags
match, but I don’t see a way in the documentation to remove middleware
non-globally.
I don’t think so, at least not without splitting out your api into an
engine which would then (IIRC - engines aren’t something I’ve really
used)
have its own middleware stack.
It should however be relatively easy to write your own middleware
which,
depending on the path, either calls through to the next item in the
stack
or invokes the Rack::Etag stuff and then replace the Rack::Etag
middleware
with that
Fred