Changesets can be listed by changeset number.
The Git repository is here.
- Revision:
- 373
- Log:
Initial import of Radiant 0.9.1, which is now packaged as a gem. This is an
import of the tagged 0.9.1 source checked out from GitHub, which isn't quite
the same as the gem distribution - but it doesn't seem to be available in an
archived form and the installed gem already has modifications, so this is
the closest I can get.
- Author:
- rool
- Date:
- Mon Mar 21 13:40:05 +0000 2011
- Size:
- 6269 Bytes
| 1 | ## 0.4.0 / March 2009 |
| 2 | |
| 3 | * Ruby 1.9.1 / Rack 1.0 compatible. |
| 4 | |
| 5 | * Invalidate cache entries that match the request URL on non-GET/HEAD |
| 6 | requests. i.e., POST, PUT, DELETE cause matching cache entries to |
| 7 | be invalidated. The cache entry is validated with the backend using |
| 8 | a conditional GET the next time it's requested. |
| 9 | |
| 10 | * Implement "Cache-Control: max-age=N" request directive by forcing |
| 11 | validation when the max-age provided exceeds the age of the cache |
| 12 | entry. This can be disabled by setting the "allow_revalidate" option to |
| 13 | false. |
| 14 | |
| 15 | * Properly implement "Cache-Control: no-cache" request directive by |
| 16 | performing a full reload. RFC 2616 states that when "no-cache" is |
| 17 | present in the request, the cache MUST NOT serve a stored response even |
| 18 | after successful validation. This is slightly different from the |
| 19 | "no-cache" directive in responses, which indicates that the cache must |
| 20 | first validate its entry with the origin. Previously, we implemented |
| 21 | "no-cache" on requests by passing so no new cache entry would be stored |
| 22 | based on the response. Now we treat it as a forced miss and enter the |
| 23 | response into the cache if it's cacheable. This can be disabled by |
| 24 | setting the "allow_reload" option to false. |
| 25 | |
| 26 | * Assume identical semantics for the "Pragma: no-cache" request header |
| 27 | as the "Cache-Control: no-cache" directive described above. |
| 28 | |
| 29 | * Less crazy logging. When the verbose option is set, a single log entry |
| 30 | is written with a comma separated list of trace events. For example, if |
| 31 | the cache was stale but validated, the following log entry would be |
| 32 | written: "cache: stale, valid, store". When the verbose option is false, |
| 33 | no logging occurs. |
| 34 | |
| 35 | * Added "X-Rack-Cache" response header with the same comma separated trace |
| 36 | value as described above. This gives some visibility into how the cache |
| 37 | processed the request. |
| 38 | |
| 39 | * Add support for canonicalized cache keys, as well as custom cache key |
| 40 | generators, which are specified in the options as :cache_key as either |
| 41 | any object that has a call() or as a block. Cache key generators get |
| 42 | passed a request object and return a cache key string. |
| 43 | |
| 44 | ## 0.3.0 / December 2008 |
| 45 | |
| 46 | * Add support for public and private cache control directives. Responses |
| 47 | marked as explicitly public are cached even when the request includes |
| 48 | an Authorization or Cookie header. Responses marked as explicitly private |
| 49 | are considered uncacheable. |
| 50 | |
| 51 | * Added a "private_headers" option that dictates which request headers |
| 52 | trigger default "private" cache control processing. By default, the |
| 53 | Cookie and Authorization headers are included. Headers may be added or |
| 54 | removed as necessary to change the default private logic. |
| 55 | |
| 56 | * Adhere to must-revalidate/proxy-revalidate cache control directives by |
| 57 | not assigning the default_ttl to responses that don't include freshness |
| 58 | information. This should let us begin using default_ttl more liberally |
| 59 | since we can control it using the must-revalidate/proxy-revalidate directives. |
| 60 | |
| 61 | * Use the s-maxage Cache-Control value in preference to max-age when |
| 62 | present. The ttl= method now sets the s-maxage value instead of max-age. |
| 63 | Code that used ttl= to control freshness at the client needs to change |
| 64 | to set the max-age directive explicitly. |
| 65 | |
| 66 | * Enable support for X-Sendfile middleware by responding to #to_path on |
| 67 | bodies served from disk storage. Adding the Rack::Sendfile component |
| 68 | upstream from Rack::Cache will result in cached bodies being served |
| 69 | directly by the web server (instead of being read in Ruby). |
| 70 | |
| 71 | * BUG: MetaStore hits but EntityStore misses. This would 500 previously; now |
| 72 | we detect it and act as if the MetaStore missed as well. |
| 73 | |
| 74 | * Implement low level #purge method on all concrete entity store |
| 75 | classes -- removes the entity body corresponding to the SHA1 key |
| 76 | provided and returns nil. |
| 77 | |
| 78 | * Basically sane handling of HEAD requests. A HEAD request is never passed |
| 79 | through to the backend except when transitioning with pass!. This means |
| 80 | that the cache responds to HEAD requests without invoking the backend at |
| 81 | all when the cached entry is fresh. When no cache entry exists, or the |
| 82 | cached entry is stale and can be validated, the backend is invoked with |
| 83 | a GET request and the HEAD is handled right before the response |
| 84 | is delivered upstream. |
| 85 | |
| 86 | * BUG: The Age response header was not being set properly when a stale |
| 87 | entry was validated. This would result in Age values that exceeded |
| 88 | the freshness lifetime in responses. |
| 89 | |
| 90 | * BUG: A cached entry in a heap meta store could be unintentionally |
| 91 | modified by request processing since the cached objects were being |
| 92 | returned directly. The result was typically missing/incorrect header |
| 93 | values (e.g., missing Content-Type header). [dkubb] |
| 94 | |
| 95 | * BUG: 304 responses should not include entity headers (especially |
| 96 | Content-Length). This is causing Safari/WebKit weirdness on 304 |
| 97 | responses. |
| 98 | |
| 99 | * BUG: The If-None-Match header was being ignored, causing the cache |
| 100 | to send 200 responses to matching conditional GET requests. |
| 101 | |
| 102 | ## 0.2.0 / 2008-10-24 / Initial Release |
| 103 | |
| 104 | * Document events and transitions in `rack/cache/config/default.rb` |
| 105 | * Basic logging support (`trace`, `warn`, `info`, `error` from within Context) |
| 106 | * EntityStore: store entity bodies keyed by SHA |
| 107 | * MetaStore: store response headers keyed by URL |
| 108 | * Last-Modified/ETag validation |
| 109 | * Vary support |
| 110 | * Implement error! transition |
| 111 | * New Rack::Cache::Core |
| 112 | * memcached meta and entity store implementations |
| 113 | * URI based storage configuration |
| 114 | * Read options from Rack env if present (rack-cache.XXX keys) |
| 115 | * `object` is now `entry` |
| 116 | * Documentation framework and website |
| 117 | * Document storage areas and implementations |
| 118 | * Document configuration/events |
| 119 | |
| 120 | ## 0.1.0 / 2008-07-21 / Proof of concept (unreleased) |
| 121 | |
| 122 | * Basic core with event support |
| 123 | * `#import` method for bringing in config files |
| 124 | * Freshness based expiration |
| 125 | * RFC 2616 If-Modified-Since based validation |
| 126 | * A horribly shitty storage back-end (Hash in mem) |
| 127 | * Don't cache hop-by-hop headers: Connection, Keep-Alive, Proxy-Authenticate, |
| 128 | Proxy-Authorization, TE, Trailers, Transfer-Encoding, Upgrade |
