On Tue, May 12, 2009 at 6:21 AM, Travis Bell <travi...@gmail.com> wrote:
> QQ: rack-cache doesn't seem to be doing it's job and I am not sure
> why...
>
> app.rb
> ----------
> require 'rubygems'
> require 'rack/cache'
> require 'sinatra'
>
> use Rack::Cache do
> set :verbose, true
> set :metastore, "file:cache/meta"
> set :entitystore, "file:cache/body"
> end
That should be:
use Rack::Cache,
:verbose => true,
:metastore => "file:cache/meta",
:entitystore => "file:cache/body"
The block form used in your original example hasn't been supported for
some time. I looked around a bit and found that the storage doc
(http://tomayko.com/src/rack-cache/storage) was using the old syntax
-- I assume this is where you got that syntax... The doc is updated
now. Sorry about that.
Your configuration still should have worked but the Heap storage
backend would have been used.
> get '/test' do
> response["Cache-Control"] = "max-age=300, public"
> erb :test
> end
> ----------
>
> I was under the impression this would cache /test for me, for 5
> minutes but all I see in the logs are:
>
> # cache: [GET /test] stale, invalid, store
>
> Is there something else I need to do?
You're probably running up against the reload/revalidate controls
added to 0.4. The "allow_reload" and "allow_revalidate" options were
added and allow the client to perform forced reload and revalidate
requests. I assume you were hitting "refresh" in your browser, which
causes a "Cache-Control: max-age=0" header to be included in the
request. This causes the cache to assume its copy is stale when the
"allow_revalidate" option is enabled. You can read more about the
"allow_revalidate" and "allow_reload" options on the configuration
page:
http://tomayko.com/src/rack-cache/configuration
Rack::Cache 0.5 no longer enables these options by default. This
breaks RFC 2616 but is the expected configuration in a majority of
gateway cache setups. You should be able to correct the issue by
upgrading to 0.5 or explicitly setting the options to false in 0.4.
Thanks,
Ryan