tdebarochez / connect-cache Goto Github PK

the file connect-cache.js uses the default ttl instead of the ttl specified with each rule.

fix on line 100: use ttl instead of options.ttl

there's also a bug in memory.js on line 19:
replace cb(null); with cb && cb(null);

besides this, i really like your library! :)

If a client sends the "cache-control" value "no-cache" connect-cach completely ignores caching.
In my opinion this is wrong and for me a not desired behavior.

Due to https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4 a client can request "no-cache" for forcing an end-to-end reload. This is done in connect-cach. But the response is not cached. In my opinion the newly loaded content (= response) is allowed to and should be cached.

Additionally I would like to see a swicth which completely ignores the "cache-control" header in client requests - to force caching even if the client requests something different.

My scenario:
I have a local development web server with live reload of my web app. I am proxying and caching external libraries from content delivery networks for traffic and performance reasons with connect-cache. In chrome I hit CTRL+F5 to reload with invalidating the cache (on client and server side). Chrome sends "no-cache" wich is ok - content should be (re-)loaded from the origin. But my next regular reload (Key F5) should come from the (server) cache.

URLs should be treated case insensitive since Express does so, to avoid duplicate caches.
https://groups.google.com/forum/#!topic/express-js/ta-59SfB180

With some storage engine, it's could be more efficient to store datas & metas together (ie: CouchDB)

it would be very useful if you could add the cache-control feature like in connect's static middleware, so when the browser have the same data like connect-cache in the cache you don't need to send the data again.

https://github.com/senchalabs/connect/blob/master/lib/middleware/static.js#L161-180