On Sep 18, 2009, at 1:31 PM, John McCaffrey <[email protected]> wrote: > Thanks for pointing out redbot.org, its very handy. I used it > against my own heroku site prawn.heroku.com (examples of how to > generate pdfs in rails with the Prawn, prawn-to libraries), and I > noticed that the server times would vary as I refreshed the page. > > http://redbot.org/?uri=http://prawn.heroku.com > > the first time I hit it, the server time was considered to be > correct, but subsequent refreshes returned anywhere from 5mins ahead > to 6hrs ahead. I assume this is just at the nginx server, and > doesn't mean that the server time on my rails server is out of sync. > > Am I reading this right?
The clock being off is actually a bug in Nginx and something we should have fixed when we upgrade to the latest major rev. Nginx overwrites the value of the Date header with the current time. The Date header is supposed to be the time when the response was first generated at the origin, not the time of the current request. Date + Age should equal the current time. This could interfere with caches between clients and Heroku but it's unlikely. Thanks, Ryan > > Hi Thomas, > > Thanks for the detailed example. It looks like Varnish is assuming a > default max-age of ~500 seconds since the Cache-Control header is set > to public but no explicit max-age is specified and the must-revalidate > directive isn't provided. redbot.org is an invaluable resource in > debugging these types of issues: > > http://redbot.org/?uri=http%3A%2F%2Ftest-caching.heroku.com%2F > > Most HTTP caches support "heuristic expiration" (details here: > http://tools.ietf.org/html/rfc2616#page-80). The basic idea is that, > if no explicit expiration time/age is provided, the cache uses a > heuristic to determine expiration, typically based on the > Last-Modified header. > > You have a few options here. If you'd like to force the cache to > always validate the response with the backend, you can set the > "must-revalidate" cache-control directive. Somewhere before the call > to stale?: > > response.headers['Cache-Control'] = "public, must-revalidate" > > That tells the cache that it's not allowed to serve a stale response > and that it must validate its version with the backend. > > Alternatively, you can set the max-age directive to zero. This has > pretty much the same effect but looks a lot nicer because Rails has a > controller method for it: > > expires_in 0, :public => true > > Give those a shot and let me know what happens. I'm also not sure I > like that Varnish does heuristic expiration by default, even though > it's to spec. > > Thanks, > Ryan > > > > > > -- > Cheers > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
