EsiGate 3.4 new caching system: a first step towards EsiGate 4.0

EsiGate 3.4 represents a major change regarding the caching system: Initially a specific caching system had to be developed as Apache HttpClient project did not offer any caching system and there were no other open source http cache implementations (as defined in the HTTP 1.1 specification).

Now since version 4.1 Apache HttpClient has its own cache. Of course there were some differences between the 2 caches so that some features may be lost, but there were also many new interesting features. 1 important thing to consider was that our cache implementation represented 20% of the code of EsiGate and maintaining it was a lot of work. Replacing it would reduce our code base and give more time to the developers to concentrate on other features.

So the decision was taken to migrate and this was achieved in version 3.4.

Here is a comparison of the features we had before and what we have now:

unchanged features:

• content expiration (depending on Cache-Control and Expires header)
• heuristic expiration (when no expiration specified in headers)
• forced expiration (defined at provider's level ignoring all cache http headers)
• variants depending on E-tag and Vary headers
• cache revalidation (conditional requests If-modified-since, If-none-match...)
• stale cache entry if error

new features:

• background revalidation
• MemCached Backend
• EhCache / Terracotta

lost features:

• OsCache backend
• local fallback resources (but you can do almost the same thing by configuring your backend with a persistent disk cache and stale if error feature)

Before migrating from EsiGate 3.3 to EsiGate 3.4 note that there has been a lot of changes in the configuration options so you will have to review all your configuration.