This should be automatic. You can use some plugins like firebug to check headers.
On Fri, Jan 27, 2012 at 8:32 AM, Carson Gross <[email protected]> wrote: > Hi Oren, > > Thanks for the links. After reading through them, my best theory for > the reason Chrome is aggressively reloading some resources I'd prefer > that it didn't is because of the relatively recent Last-Modified > headers coming from Varnish. Is there a way to tie the Last-Modified > header back to when we last deployed? > > Thanks, > Carson > > On Jan 26, 10:22 pm, Oren Teich <[email protected]> wrote: >> There are different types of caches - client and server side. >> Check out this presentation to learn more about what's going on: >> >> http://tomayko.com/writings/railsconf-caching-talkhttp://www.slideshare.net/rtomayko/https-bestkept-secret-cachinghttp://tomayko.com/writings/things-caches-dohttp://tomayko.com/writings/rack-cache-announce >> >> Oren >> >> On Thu, Jan 26, 2012 at 9:53 PM, Carson Gross <[email protected]> wrote: >> >> >> >> >> >> >> >> > And one last note: due to the way some of these resources are included >> > (e.g. the stylesheet_link_tag method in rails) they end up with a >> > query string. >> >> > Reading online, it appears that resources with a query string are not >> > supposed to be cached, but that the major browsers ignore that. >> >> > Anyone know for sure? >> >> > Thanks, >> > Carson >> >> > On Jan 26, 9:41 pm, Carson Gross <[email protected]> wrote: >> >> OK, now that I have my head around what is going on, it appears that >> >> the static stuff is being cached and served up via Varnish. >> >> >> It appears that my browser is not respecting the varish response >> >> though. The response has the following header: >> >> >> Cache-Control:public, max-age=43200 >> >> >> and yet another request is made when I hit cmd-r. When I click >> >> around, I still see requests for this resource, with the 304 response >> >> code. >> >> >> I'm using Chrome. >> >> >> UPDATE: >> >> >> OK, digging a bit more, I found this page: >> >> >> http://code.google.com/speed/page-speed/docs/caching.html >> >> >> In particular, I note this bit: >> >> >> "Set the Last-Modified date to the last time the resource was changed. >> >> If the Last-Modified date is sufficiently far enough in the past, >> >> chances are the browser won't refetch it." >> >> >> And, looking more closely at the response headers, I see this: >> >> >> Cache-Control:public, max-age=43200 >> >> Connection:keep-alive >> >> Date:Fri, 27 Jan 2012 05:31:46 GMT >> >> Last-Modified:Thu, 26 Jan 2012 17:14:44 GMT >> >> Server:nginx >> >> Via:1.1 varnish >> >> X-Varnish:800861986 >> >> >> And note that the Last-Modified date is today, even though we haven't >> >> deployed a new version of our app for a while, which I believe may be >> >> why Chrome is issuing requests for the resources even though it isn't >> >> changing. >> >> >> When I resubmit, I see a different Last-Modified header for the same >> >> resource. >> >> >> So my guess here is that the Last-Modified header is generated by the >> >> change date of the file on a particular instance of Varnish, and that >> >> various instances are coming up and going down, causing the Last >> >> Modified date to be relatively recent, causing Chrome to submit more >> >> requests to the server than I'd like. >> >> >> Does that sound at all plausible? >> >> >> Thanks, >> >> Carson >> >> >> On Jan 26, 5:56 pm, Carson Gross <[email protected]> wrote: >> >> >> > Looking at it a bit more (as well as some *yikes* requests to our >> >> > server) I see that we are getting a ton of 304s, which are, no doubt, >> >> > tying up our dynos. >> >> >> > So, this may be more of a rails question than a heroku question, but >> >> > how can I set expires headers on certain static directories? >> >> >> > Yes, I am a complete and utter newb at this. >> >> >> > Cheers, >> >> > Carson >> >> >> > On Jan 26, 5:00 pm, Carson Gross <[email protected]> wrote: >> >> >> > > Heya, >> >> >> > > Sorry, digging through the docs I couldn't really get an answer on >> >> > > this that I understand: >> >> >> > > So, with static assets, deployed on the bamboo-ree-1.8.7 stack, are >> >> > > static assets served by web dynos? As our application has grown over >> >> > > time, we've evolved to issue a horrific number of requests for static >> >> > > content (css, javascript, etc.) and I'm trying to understand just how >> >> > > bad that is for our performance. Seems like we'd be tying up web >> >> > > dynos, but I want to make sure. >> >> >> > > Secondly, given that I don't feel like rewriting all that code right >> >> > > now, is there a way to map certain paths to a heroku app to another >> >> > > server, so we aren't hammering our dynos so badly? >> >> >> > > Thanks, >> >> > > Carson >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Heroku" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group >> > athttp://groups.google.com/group/heroku?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
