Feature: Obey Cache-Control about apicache HOT 2 CLOSED

For completeness sake here is a basic checklist

Cache Bypasses
cache-control: no-cache (shouldn't be cached)
cache-control: no-store (used for sensitive info, shouldn't be cached)
cache-control: private (shouldn't be cached)
cache-control: must-revalidate (note this has special behaviour)
pragma: no-cache (prior to the implementation of cache-control: no-cache, this was generally used in the past)

Setting Timeouts
cache-control: max-age (timeout should be honoured)
cache-control: s-maxage (timeout should be honoured - shared cache)
expires: 0 (timeout should be honoured, note: 0 is basically another cache bypass)

Etag
etag - Because etag.

Vary
vary - Because vary.

from apicache.

@willfarrell This is specifically for request caching where the server maintains control (usually to protect against computationally expensive runs like database calls, processing, etc). If we honor every cache bypass (e.g. max-age=0, no-cache, etc) sent from the client, a hard refresh from any browser suddenly forces a cache-bypass across the board, hitting those expensive requests again even if the server deems that nothing has changed (or surely you would have cleared the cache after such changes).

We have "x-apicache-bypass" as an off-the-grid way to explicitly force from the client without being accidentally triggered from a standard practice.

I may put in a toggle to enable/disable basic client bypasses using these methods in an upcoming minor release if there is enough interest.

from apicache.