Rack-cache 0.3.0

Ruby
1

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/

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