Forum: Ruby on Rails Rails Default ETag Generation

Posted by jcoleman (Guest)
on 2012-10-03 11:32
(Received via mailing list)
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?
Posted by Frederick Cheung (Guest)
on 2012-10-03 12:14
(Received via mailing list)
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
Posted by jcoleman (Guest)
on 2012-10-03 15:12
(Received via mailing list)
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.
Posted by Frederick Cheung (Guest)
on 2012-10-03 17:15
(Received via mailing list)
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
Posted by jcoleman (Guest)
on 2012-10-03 19:09
(Received via mailing list)
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!
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.