Requesting "no-cache" does not cache reloaded content

[Kyrodan]

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.

[tdebarochez]

Your issue looks like https://github.com/tdebarochez/connect-cache/issues/2 isn't it ?

[Kyrodan]

Your issue looks like #2 isn't it ?

No, it's not. Issue #2 describes a method to not send (already cached and) unmodified content again (e. g. ETag-Handling in todays apps). This issue simply likes forced-reloaded content to get cached in connect-cache for the next request(s). It's simply invalidating the requested resource in cache and doing everything else what connect-cache normaly does after this invalidation.