[ANN] rack-cache 0.3.0
- From: Ryan Tomayko <rtomayko@xxxxxxxxx>
- Date: Mon, 29 Dec 2008 06:13:47 -0500
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
.
- Prev by Date: Problems about requiring gems
- Next by Date: Re: Few Questions on Ruby
- Previous by thread: Problems about requiring gems
- Next by thread: rexml system error on parse
- Index(es):
Relevant Pages
|
