Thanks, that does seem to be exactly what I'm looking for. Alas, there doesn't seem to be a way to build a caching http client on a specific policy object, or to get the policy object being used by a caching http client. I could try to construct a policy object using the same values as the caching http client, but that would seem to risk drift if and as the impl varies. Is there some mechanism I am missing or is this just the way things are right now?
I appreciate your response and, indeed, your contribution of the caching client. On Fri, Jul 1, 2016 at 12:34 PM, Oleg Kalnichevski <[email protected]> wrote: > On Fri, 2016-07-01 at 00:04 -0400, Donald Ball wrote: > > Hi folks. I'm using the caching http client to nice effect, thanks for > the > > good work. > > > > Since parsing json and other structured response bodies is not actually > the > > fastest process in the world, I thought it would be a useful optimization > > to build a parsed body cache atop the http caching client. I've written > one > > and it does work fine, but there is an annoying wrinkle: I don't know > > whether or not a given response is cacheable except by observing from the > > context's cache response if the response was in some way served from the > > cache. This results in having to perform two parses on a given body > before > > it can be served from the parsed body cache. It's not the end of the > world, > > but it's not optimal. > > > > Is there some way that I have overlooked by which I can tell if a given > > response is cacheable? > > > > I appreciate any thoughts. Thanks. > > Have you looked at ResponseCachingPolicy? > > > http://hc.apache.org/httpcomponents-client-4.5.x/httpclient-cache/xref/org/apache/http/impl/client/cache/ResponseCachingPolicy.html > > Its #isResponseCacheable method is likely what you want. > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
