Commits on Mar 7, 2009
  1. Remove dead code and some refactoring ...

    * Removed freshness_information?
    * Removed redundant Header mixin from Request and Response
    * Removed Headers#[] accessor methods
    * Removed unused Response#freeze
    * Removed unused Response#public=
    * Removed unused Response#stale?
    * Removed original_request; the @env goes downstream
    Daniel Mendler committed with rtomayko Mar 7, 2009
  2. Remove busters.rb and no-cache.rb config files

    Daniel Mendler committed with rtomayko Mar 7, 2009
  3. Invalidate instead of purge on non-GET/POST requests

    Sets the Age header to the max_age + 1 before storing the
    entry, causing it to be invalid the next time its retrieved from
    cache. The Age header is no longer written when storing fresh/valid
    Daniel Mendler committed with rtomayko Mar 7, 2009
Commits on Mar 5, 2009
  1. Invalidation specs

    rtomayko committed Mar 5, 2009
  2. Simplify logging considerably

    rtomayko committed Mar 5, 2009
  3. Cache invalidation on POST, PUT, DELETE ...

    We invalidate on anything that's not a GET or HEAD request,
    Daniel Mendler committed with rtomayko Mar 4, 2009
  4. Include PATH_INFO in cache log output

    Daniel Mendler committed with rtomayko Mar 4, 2009
Commits on Feb 10, 2009
Commits on Feb 8, 2009
  1. Remove configuration language entirely

    The event system is gone. This was over-engineering on my part,
    plain and simple. As more of RFC 2616 was implemented, the more it
    became apparent that a configuration language is simply not
    necessary. Setting the appropriate Cache-Control headers at the
    origin solves a majority of the problems that Varnish solves with
    VCL. The other problems can be implemented with Rack middleware
    components placed before or after Rack::Cache.
    This is going to let me clean house and remove a ton of extra
    complexity needed only to prop up the configuration language.
    rtomayko committed Feb 8, 2009
  2. TODO update

    rtomayko committed Feb 8, 2009
Commits on Feb 4, 2009
  1. Don't URI encode cache keys at the generic metastore level

    The underlying metastore implementation is responsible for
    escaping keys as necessary.
    rtomayko committed Feb 4, 2009
  2. Add scheme, port to canonized key; revise query string cleaning

    * The scheme was added to the canonized key because a site can
    theoretically have different content or cache policy on SSL vs
    non-ssl versions of the site. The port was added for similar reasons.
    * We can't use Request#params for the query string because this
    will return a nested Hash structure in Rack 1.0. It also reads
    params from POST bodies.
    rtomayko committed Feb 4, 2009
  3. Added :cache_key option - customizable cache key logic

    You can specify an alternative cache key generator that is
    either a class that responds to .call() or is just a simple
    block. Also added the ability to set blocks as options in
    the configuration language.
    nakajima committed with rtomayko Feb 3, 2009
  4. Canonicalized cache keys

    Adds a Rack::Cache::Key class, which should make it much easier to
    allow people to provide their own custom formatters. Still need to
    move the tests out of metastore test.
    nakajima committed with rtomayko Feb 2, 2009
  5. Example Sinatra app

    nakajima committed with rtomayko Feb 1, 2009
Commits on Dec 30, 2008
  1. Fixed bug caused by unknown header method.

    * Updated Regexp to match no-cache directive more precisely
    Signed-off-by: Ryan Tomayko <>
    Dan Kubb committed with rtomayko Dec 30, 2008
Commits on Dec 29, 2008
  1. Updated Headers#cache_control to strip leading/trailing spaces

    * Simplified parsing code.  A Header value should not contain any
      whitespace characters, other than space, so using String#delete to
      remove the space is simpler than using split with \s* to strip
    * If the Cache-Control header contains leading or trailing spaces
      it would have been parsed incorrectly prior to this fix.
    Dan Kubb committed Dec 29, 2008
Commits on Dec 28, 2008
  1. proper support for private/public Cache-Control directives

    * Responses marked as explicitly public are cached even when the
      request includes an Authorization or Cookie header. Responses
      marked as explicitly private are considered uncacheable.
    * Added a "private_headers" option that dictates which request
      headers trigger "private" cache control processing. By default,
      the Cookie and Authorization headers are included. Headers may be
      added or removed as necessary to change the default private logic.
    rtomayko committed Dec 28, 2008
Commits on Dec 22, 2008
  1. respect must-revalidate cache control directives

    Adhere to must-revalidate/proxy-revalidate cache control directives
    by not assigning the default_ttl to responses that don't include
    freshness information. This should let us begin using default_ttl
    more liberally since we can control it from the origin using
    rtomayko committed Dec 22, 2008