[ANN] rack-cache 0.3.0

rack-cache 0.3.0 is now available. This release corrects some nasty
bugs and adds support for a variety of important HTTP caching features.

http://tomayko.com/src/rack-cache/
http://github.com/rtomayko/rack-cache/

From the CHANGES file:

* Add support for public and private 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 default "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.

* 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 using
 the must-revalidate/proxy-revalidate directives.

* Use the s-maxage Cache-Control value in preference to max-age
 when present. The ttl= method now sets the s-maxage value instead
 of max-age.  Code that used ttl= to control freshness at the
 client needs to change to set the max-age directive explicitly.

* Enable support for X-Sendfile middleware by responding to
 #to_path on bodies served from disk storage. Adding the
 Rack::Sendfile component upstream from Rack::Cache will result in
 cached bodies being served directly by the web server (instead of
 being read in Ruby).

* BUG: MetaStore hits but EntityStore misses. This would 500
 previously; now we detect it and act as if the MetaStore missed
 as well.

* Implement low level #purge method on all concrete entity store
 classes -- removes the entity body corresponding to the SHA1 key
 provided and returns nil.

* Basically sane handling of HEAD requests. A HEAD request is
 never passed through to the backend except when transitioning
 with pass!. This means that the cache responds to HEAD requests
 without invoking the backend at all when the cached entry is
 fresh. When no cache entry exists, or the cached entry is stale
 and can be validated, the backend is invoked with a GET request
 and the HEAD is handled right before the response is delivered
 upstream.

* BUG: The Age response header was not being set properly when a
 stale entry was validated. This would result in Age values that
 exceeded the freshness lifetime in responses.

* BUG: A cached entry in a heap meta store could be
 unintentionally modified by request processing since the cached
 objects were being returned directly. The result was typically
 missing/incorrect header values (e.g., missing Content-Type
 header). [dkubb]

* BUG: 304 responses should not include entity headers
 (especially Content-Length). This is causing Safari/WebKit
 weirdness on 304 responses.

* BUG: The If-None-Match header was being ignored, causing the
 cache to send 200 responses to matching conditional GET requests.

Thanks,
Ryan