rack-cache 0.3.0 → 0.4

data/CHANGES

@@ -1,3 +1,46 @@
+## 0.4.0 / March 2009
+
+  * Ruby 1.9.1 / Rack 1.0 compatible.
+
+  * Invalidate cache entries that match the request URL on non-GET/HEAD
+    requests. i.e., POST, PUT, DELETE cause matching cache entries to
+    be invalidated. The cache entry is validated with the backend using
+    a conditional GET the next time it's requested.
+
+  * Implement "Cache-Control: max-age=N" request directive by forcing
+    validation when the max-age provided exceeds the age of the cache
+    entry. This can be disabled by setting the "allow_revalidate" option to
+    false.
+
+  * Properly implement "Cache-Control: no-cache" request directive by
+    performing a full reload. RFC 2616 states that when "no-cache" is
+    present in the request, the cache MUST NOT serve a stored response even
+    after successful validation. This is slightly different from the
+    "no-cache" directive in responses, which indicates that the cache must
+    first validate its entry with the origin. Previously, we implemented
+    "no-cache" on requests by passing so no new cache entry would be stored
+    based on the response. Now we treat it as a forced miss and enter the
+    response into the cache if it's cacheable. This can be disabled by
+    setting the "allow_reload" option to false.
+
+  * Assume identical semantics for the "Pragma: no-cache" request header
+    as the "Cache-Control: no-cache" directive described above.
+
+  * Less crazy logging. When the verbose option is set, a single log entry
+    is written with a comma separated list of trace events. For example, if
+    the cache was stale but validated, the following log entry would be
+    written: "cache: stale, valid, store". When the verbose option is false,
+    no logging occurs.
+
+  * Added "X-Rack-Cache" response header with the same comma separated trace
+    value as described above. This gives some visibility into how the cache
+    processed the request.
+
+  * Add support for canonicalized cache keys, as well as custom cache key
+    generators, which are specified in the options as :cache_key as either
+    any object that has a call() or as a block. Cache key generators get
+    passed a request object and return a cache key string.
+
 ## 0.3.0 / December 2008
 
   * Add support for public and private cache control directives. Responses

data/README

@@ -12,7 +12,6 @@ validation (Last-Modified, ETag) information:
   * Cache-Control: public, private, max-age, s-maxage, must-revalidate,
     and proxy-revalidate.
   * Portable: 100% Ruby / works with any Rack-enabled framework
-  * Configuration language for advanced caching policies
   * Disk, memcached, and heap memory storage backends
 
 For more information about Rack::Cache features and usage, see:
@@ -25,14 +24,6 @@ caching solution for small to medium sized deployments. More sophisticated /
 high-performance caching systems (e.g., Varnish, Squid, httpd/mod-cache) may be
 more appropriate for large deployments with significant throughput requirements.
 
-Status
-------
-
-Rack::Cache is a young and experimental project that is likely to change
-substantially and may not be wholly functional, consistent, fast, or correct.
-The current focus is on reaching basic compliance with RFC 2616 and providing
-good documentation.
-
 Installation
 ------------
 
@@ -66,6 +57,24 @@ Assuming you've designed your backend application to take advantage of HTTP's
 caching features, no further code or configuration is required for basic
 caching.
 
+Using with Rails
+----------------
+
+Add this to your `config/environment.rb`:
+
+   config.middleware.use Rack::Cache,
+       :verbose => true,
+       :metastore   => 'file:/var/cache/rack/meta',
+       :entitystore => 'file:/var/cache/rack/body'
+
+You should now see `Rack::Cache` listed in the middleware pipeline:
+
+    rake middleware
+
+See the following for more information:
+
+    http://snippets.aktagon.com/snippets/302
+
 Links
 -----
 

data/Rakefile

@@ -31,7 +31,7 @@ end
 
 # DOC =======================================================================
 desc 'Build all documentation'
-task :doc => %w[doc:api doc:graphs doc:markdown]
+task :doc => %w[doc:api doc:markdown]
 
 # requires the hanna gem:
 #   gem install mislav-hanna --source=http://gems.github.com
@@ -55,19 +55,6 @@ file 'doc/api/index.html' => FileList['lib/**/*.rb'] do |f|
 end
 CLEAN.include 'doc/api'
 
-desc 'Build graphviz graphs'
-task 'doc:graphs'
-%w[pdf png svg].each do |filetype|
-  FileList["doc/*.dot"].each do |source|
-    dest = source.sub(/dot$/, filetype)
-    file dest => source do |f|
-      sh "dot -T#{filetype} #{source} -o #{f.name}"
-    end
-    task 'doc:graphs' => dest
-    CLEAN.include dest
-  end
-end
-
 desc 'Build markdown documentation files'
 task 'doc:markdown'
 FileList['doc/*.markdown'].each do |source|

data/TODO

@@ -1,21 +1,20 @@
-## 0.4
-
-  - liberal, conservative, sane caching configs
-  - Sample apps: Rack, Rails, Sinatra, Merb, etc.
-  - busters.rb and no-cache.rb doc and tests
-  - Canonicalized URL for cache key:
-    - sorts params by key, then value
-    - urlencodes /[^ A-Za-z0-9_.-]/ host, path, and param key/value
-  - Custom cache keys
-  - Cache invalidation on PUT, POST, DELETE.
-    - Invalidate at the request URI; or, anything that's "near" the request URI.
-    - Invalidate at the URI of the Location or Content-Location response header.
-
 ## Backlog
 
+  - Move breakers.rb configuration file into rack-contrib as a middleware
+    component.
+  - Sample apps: Rack, Rails, Sinatra, Merb, etc.
+  - Use Bacon instead of test/spec
+  - Work with both memcache and memcached gems (memcached hasn't built on MacOS
+    for some time now).
+  - Fast path pass processing. We do a lot more than necessary just to determine
+    that the response should be passed through untouched.
+  - Don't purge/remove cache entries when invalidating. The entries should be
+    marked as stale and be forced revalidated on the next request instead of
+    being removed entirely.
   - Add missing Expires header if we have a max-age.
-  - Purge/invalidate specific cache entries
   - Purge/invalidate everything
+  - Invalidate at the URI of the Location or Content-Location response header
+    on POST, PUT, or DELETE that results in a redirect.
   - Maximum size of cached entity
   - Last-Modified factor: requests that have a Last-Modified header but no Expires
     header have a TTL assigned based on the last modified age of the response:

data/doc/configuration.markdown

@@ -1,51 +1,17 @@
-Configuration Language
-======================
+Configuration
+=============
 
 __Rack::Cache__ includes a configuration system that can be used to specify
 fairly sophisticated cache policy on a global or per-request basis.
 
-  - [Synopsis](#synopsis)
-  - [Setting Cache Options](#setopt)
-  - [Cache Option Reference](#options)
-  - [Configuration Machinery - Events and Transitions](#machinery)
-  - [Importing Configuration](#import)
-  - [Default Configuration Machinery](#default)
-  - [Notes](#notes)
-
-<a id='synopsis'></a>
-
-Synopsis
---------
-
-    use Rack::Cache do
-      # set cache related options
-      set :verbose, true
-      set :metastore,   'memcached://localhost:11211'
-      set :entitystore, 'file:/var/cache/rack/body'
-
-      # override events / transitions
-      on :receive do
-        pass! if request.url =~ %r|/dontcache/|
-        error! 402 if request.referrer =~ /digg.com/
-      end
-
-      on :miss do
-        trace 'missed: %s', request.url
-      end
-
-      # bring in other configuration machinery
-      import 'rack/cache/config/breakers'
-      import 'mycacheconfig'
-    end
-
 <a id='setopt'></a>
 
 Setting Cache Options
 ---------------------
 
-Cache options can be set when the __Rack::Cache__ object is created; or by using
-the `set` method within a configuration block; or by setting a
-`rack-cache.<option>` variable in __Rack__'s __Environment__.
+Cache options can be set when the __Rack::Cache__ object is created,
+or by setting a `rack-cache.<option>` variable in __Rack__'s
+__Environment__.
 
 When the __Rack::Cache__ object is instantiated:
 
@@ -54,14 +20,6 @@ When the __Rack::Cache__ object is instantiated:
       :metastore => 'memcached://localhost:11211/',
       :entitystore => 'file:/var/cache/rack'
 
-Using the `set` method within __Rack::Cache__'s configuration context:
-
-    use Rack::Cache do
-      set :verbose, true
-      set :metastore, 'memcached://localhost:11211/'
-      set :entitystore, 'file:/var/cache/rack'
-    end
-
 Using __Rack__'s __Environment__:
 
     env.merge!(
@@ -123,110 +81,6 @@ If any of these headers are present in the request, the response is considered
 private and will not be cached _unless_ the response is explicitly marked public
 (e.g., `Cache-Control: public`).
 
-<a id='machinery'></a>
-
-Configuration Machinery - Events and Transitions
-------------------------------------------------
-
-The configuration machinery is built around a series of interceptable events and
-transitions controlled by a simple configuration language. The following diagram
-shows each state (interceptable event) along with their possible transitions:
-
-<p class='center'>
-<img src='events.png' alt='Events and Transitions Diagram' />
-</p>
-
-Custom logic can be layered onto the `receive`, `hit`, `miss`, `fetch`, `store`,
-`deliver`, and `pass` events by passing a block to the `on` method:
-
-    on :fetch do
-      trace 'fetched %p from backend application', request.url
-    end
-
-Here, the `trace` method writes a message to the `rack.errors` stream when a
-response is fetched from the backend application. The `request` object is a
-[__Rack::Cache::Request__](./api/classes/Rack/Cache/Request) that can be
-inspected (and modified) to determine what action should be taken next.
-
-Event blocks are capable of performing more interesting operations:
-
-  * Transition to a different event or override default caching logic.
-  * Modify the request, response, cache entry, or Rack environment options.
-  * Set the `metastore` or `entitystore` options to select a different storage
-    mechanism / location dynamically.
-  * Collect statistics or log request/response/cache information.
-
-When an event is triggered, the blocks associated with the event are executed in
-reverse/FILO order (i.e., the block declared last runs first) until a
-_transitioning statement_ is encountered. Transitioning statements are suffixed
-with a bang character (e.g, `pass!`, `store!`, `error!`) and cause the current
-event to halt and the machine to transition to the subsequent event; control is
-not returned to the original event. The [default configuration](#default)
-includes documentation on available transitions for each event.
-
-The `next` statement can be used to exit an event block without transitioning
-to another event. Subsequent event blocks are executed until a transitioning
-statement is encountered:
-
-    on :fetch do
-      next if response.freshness_information?
-
-      if request.url =~ /\/feed$/
-        trace 'feed will expire in fifteen minutes'
-        response.ttl = 15 * 60
-      end
-    end
-
-<a id='import'></a>
-
-Importing Configuration
------------------------
-
-Since caching logic can be layered, it's possible to separate various bits of
-cache policy into files for organization and reuse.
-
-    use Rack::Cache do
-      import 'rack/cache/config/busters'
-      import 'mycacheconfig'
-
-      # more stuff here
-    end
-
-The `busters` and `mycacheconfig` configuration files are normal Ruby source
-files (i.e., they have a `.rb` extension) situated on the `$LOAD_PATH` - the
-`import` statement works like Ruby's `require` statement but the contents of the
-files are evaluated in the context of the configuration machinery, as if
-specified directly in the configuration block.
-
-The `rack/cache/config/busters.rb` file makes a good example. It hooks into the
-`fetch` event and adds an impractically long expiration lifetime to any response
-that includes a cache busting query string:
-
-<%= File.read('lib/rack/cache/config/busters.rb').gsub(/^/, '    ') %>
-
-
-<a id='default'></a>
-
-Default Configuration Machinery
--------------------------------
-
-The `rack/cache/config/default.rb` file is imported when the __Rack::Cache__
-object is instantiated and before any custom configuration code is executed.
-It's useful to understand this configuration because it drives the default
-transitioning logic.
-
-<%= File.read('lib/rack/cache/config/default.rb').gsub(/^/, '    ') %>
-
-<a id='notes'></a>
-
-Notes
------
-
-The configuration language was inspired by [Varnish][var]'s
-[VCL configuration language][vcl].
-
-[var]: http://varnish.projects.linpro.no/
-  "Varnish HTTP accelerator"
+### `cache_key`
 
-[vcl]: http://tomayko.com/man/vcl
-  "VCL(7) -- Varnish Configuration Language Manual Page"
+TODO: Document custom cache keys

data/doc/faq.markdown

@@ -10,6 +10,14 @@ General
 -------
 
 
+<a class='hash' id='rails' href='#rails'>#</a>
+
+### Q: Can I use Rack::Cache with Rails?
+
+Rack::Cache can be used with Rails 2.3 or above. Documentation and a
+sample application is forthcoming; in the mean time, see
+[this example of using Rack::Cache with Rails 2.3](http://snippets.aktagon.com/snippets/302-How-to-setup-and-use-Rack-Cache-with-Rails-2-3-0-RC-1).
+
 <a class='hash' id='why-not-squid' href='#why-not-squid'>#</a>
 
 ### Q: Why Rack::Cache? Why not Squid, Varnish, Perlbol, etc.?

data/doc/index.markdown

@@ -7,16 +7,15 @@ for [Rack][]-based applications that produce freshness (`Expires`,
   * Validation
   * Vary support
   * Portable: 100% Ruby / works with any [Rack][]-enabled framework.
-  * [Configuration language][config] for advanced caching policies.
   * Disk, memcached, and heap memory [storage backends][storage].
 
-Status
-------
+News
+----
 
-__Rack::Cache__ is a young and experimental project that is likely to
-change substantially and may not be wholly functional, consistent,
-fast, or correct. The current focus is on reaching basic compliance
-with RFC 2616 and providing good documentation.
+  * [How to use Rack::Cache with Rails 2.3](http://snippets.aktagon.com/snippets/302-How-to-setup-and-use-Rack-Cache-with-Rails-2-3-0-RC-1) - it's really easy.
+  * [RailsLab's Advanced HTTP Caching Screencast](http://railslab.newrelic.com/2009/02/26/episode-11-advanced-http-caching)
+    is a really great review of HTTP caching concepts and shows how to
+    use Rack::Cache with Rails.
 
 Installation
 ------------
@@ -52,8 +51,7 @@ caching.
 More
 ----
 
-  * [Configuration Language Documentation][config] - how to customize cache
-    policy using the simple event-based configuration system.
+  * [Configuration Options][config] - how to set cache options.
 
   * [Cache Storage Documentation][storage] - detailed information on the various
     storage implementations available in __Rack::Cache__ and how to choose the one

data/example/sinatra/app.rb

@@ -0,0 +1,25 @@
+require 'sinatra'
+require 'rack/cache'
+
+use Rack::Cache do
+  set :verbose, true
+  set :metastore,   'heap:/'
+  set :entitystore, 'heap:/'
+
+  on :receive do
+    pass! if request.url =~ /favicon/
+  end
+end
+
+before do
+  last_modified $updated_at ||= Time.now
+end
+
+get '/' do
+  erb :index
+end
+
+put '/' do
+  $updated_at = nil
+  redirect '/'
+end

data/example/sinatra/views/index.erb

@@ -0,0 +1,44 @@
+<html>
+  <head>
+    <title>Sample Rack::Cache Sinatra app</title>
+    <style type="text/css" media="screen">
+      body {
+        font-family: Georgia;
+        font-size: 24px;
+        text-align: center;
+      }
+
+      #headers {
+        font-size: 16px;
+      }
+
+      input {
+        font-size: 24px;
+        cursor: pointer;
+      }
+    </style>
+  </head>
+  <body>
+    <h1>Last updated at: <%= $updated_at.strftime('%l:%m:%S%P') %></h1>
+
+    <p>
+      <form action="/" method="post">
+        <input type="hidden" name="_method" value="PUT">
+        <input type="submit" value="Expire the cache.">
+      </form>
+    </p>
+
+    <div id="headers">
+      <h3>Headers:</h3>
+
+      <% response.headers.each do |key, value| %>
+        <p><%= key %>: <%= value %></p>
+      <% end %>
+
+      <h3>Params:</h3>
+      <% params.each do |key, value| %>
+        <p><%= key %>: <%= value || '(blank)' %></p>
+      <% end %>
+    </div>
+  </body>
+</html>