CHANGES in rack-cache-0.3.0 vs CHANGES in rack-cache-0.4

@@ -1,4 +1,47 @@
+## 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
     marked as explicitly public are cached even when the request includes
     an Authorization or Cookie header. Responses marked as explicitly private