search

rtomayko / rack-cache

Real HTTP Caching for Ruby Web Apps
http://rtomayko.github.io/rack-cache/
Other
822 stars 126 forks source link

Allow setting the entity store to nil #129

Closed amatriain closed 8 years ago

amatriain commented 8 years ago

This PR adds the ability to set rack-cache entity store to nil, e.g.:

require 'rack/cache'

use Rack::Cache,
  :metastore   => 'file:/var/cache/rack/meta',
  :entitystore => nil,
  :verbose     => true

run app

When entitystore is set to nil, rack-cache doesn't persist response bodies. If a cached response is still fresh, or if it's stale but found to be still valid, rack-cache returns only the response headers with an empty body. The code performing the request should check if the response comes from the cache (e.g. checking the X-Rack-Cache header) and in in this case ignore the response body.

Obviously this is only useful for use cases in which, if a cached response is still valid, its body is not interesting.

This is useful for my particular use case but may be interesting for other people. In particular this avoids the common problem of the backend (disk in my case) filling up with old entities, because rack-cache performs no cleanup of old useless entities once there is a new response. This can be avoided with this PR by not persisting entries in the backend in the first place.

grosser commented 8 years ago

prefer using memcached or similar so garbage data is no problem ...

grosser commented 8 years ago

how about using an entity store that always returns [''] and never stores anything -> no new code needed ?

amatriain commented 8 years ago

I'm not sure what you mean. Implementing a new backend for this behavior, so that configuration would look like this instead?

require 'rack/cache'

use Rack::Cache,
  :metastore   => 'file:/var/cache/rack/meta',
  :entitystore => 'dummy://',
  :verbose     => true

run app

It would require more or less as much code as this PR, I'm not sure what you mean by no new code needed.

grosser commented 8 years ago

A separate backend would mean the code handling the response is less complex and all other users (99.9%+) don't have to pay the price of the extra if/else checks. It will also be a good example of how to deal with special usecases without having to modify the core library :)

amatriain commented 8 years ago

That's very different from the code in this PR, even if it achieves the same result. I'm going to open a different PR, see if you like that one better.