Ayende writing about choosing between implementing RavenDB cache similar to Hibernate second level cache1 or HTTP caches:
RavenDB is an HTTP server, in the end. Why not use HTTP caching? […] HTTP Caching is a somewhat complex topic, if you think it is not, talk to me after reading this 24 pages document describing it. But in essence, I am actually using only a small bit of it.
Firstly, if you really want to understand web caches I strongly recommend Mark Notthingham’s Caching tutorial for web authors and webmasters.
Getting back to Ayende’s post, a couple of comments
the mechanism described in the post is called conditional GET. According to the HTTP/1.1 RFC:
The semantics of the GET method change to a “conditional GET” if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.
an HTTP caching mechanism should also consider reversed proxies’ behavior.
For these to work freshness (
Expires) and cache-control (
Cache-control) headers must be used
without reversed proxies, query caching based only on
ETags will in most cases just reduce the bandwith (by not sending back a response), but will continue to fetch the data for calculating the query
ETag. Basically, the
benefits are smaller.
On the topic of HTTP-based caching, you should also check the article
CouchDB and Varnish caching .
Original title and link: RavenDB and HTTP Caching (NoSQL databases © myNoSQL)