Thanks for the response. And yes, I think that supports both the use cases I was thinking of.
thanks :) sam On Wed, Jun 19, 2013 at 7:02 AM, Jon Moore <[email protected]> wrote: > > On Sat, 2013-06-15 at 07:18 -0700, Sam Perman wrote: > > > I think it would be interesting to open those Apis up so the > application > > could get cache entries for use in certain error cases. (For example, my > > client app has detected the server is unavailable for some reason or I > have > > crossed some throttling limit for requests to the backend... I could > choose > > not to attempt a call to the backend and just return the cache entry > > instead.) > > > > Hi Sam, > > Many of the features you describe are already available from the > httpclient-based caching stack by modifying the requests that are sent. For > example, you can add 'Cache-Control: max-stale=31536000, only-if-cached' to > requests to prevent origin requests and get at any existing cache entries. > The caching stack also supports the stale-if-error (RFC5861) request > parameter, and will already return stale cache entries on networking errors > during revalidation. > > Do those support your use cases? > > The primary reason we've preferred to keep much of the caching APIs private > is to allow room for future refactorings without breaking API > compatibility. > > Jon >
