This was causing all kinds of confusion since refreshing in the browser always caused a cache miss. People assumed that rack-cache wasn't working at all. The allow_reload and allow_revalidate options now default to false. This breaks with RFC 2616 but is the desired config in a majority of gateway cache scenarios.
* 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 "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 from the origin using must-revalidate/proxy-revalidate.
The idea here is to allow a middleware component such as Rack::Sendfile  to intercept responses that can be served from disk and use the web-server's X-Sendfile support. http://github.com/rtomayko/rack-contrib/tree/master/lib/rack/sendfile.rb
Most entity stores can be purged behind rack-cache (e.g., memcached automatically purges based on mem use, the disk store could be purged with a cron job, etc.). This leads to a situation where the metastore could point to an entity body that no longer exists. This would result in a 500 previously but now we detect it in the metastore and act as if it was a straight miss. Ideally, we would also purge the metastore entry, since it's no longer valid and will only cause more false-hits to occur, but that's something we'll have to tackle later.
A HEAD request is never passed through to the backend except when transitioning with pass!. 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 handling is performed right before the response is delivered upstream. This probably needs to be refined a bit but its much better than the current HEAD handling -- none.
While here, fix a few issues with an initial response from cache being different from subsequent requests. The Age and X-Content-Digest headers were not present in responses to initial requests.
Fixes an issue with Safari/WebKit holding connections open when a 304 Not Modified response was generated. The Content-Length, Content-Type, and other entity headers that are supposed to be omitted from the response were not being removed properly. Also, the cache was not sending 304 responses upstream in response to conditional GET requests with If-None-Match/Etag values. Not sure how I missed that until now.