That's a good clarification. In point of fact, my higher-level cache is caching responses with etag headers, lacking any other suitable key without going to the trouble of taking into account vary headers and the like.
It seems to me that adding a method or two to the HttpCacheContext would facilitate building higher-level caches. Perhaps #getCacheKey(), which would return some opaque string e.g. the url+etag or the url+vary headers, and #isCacheableResponse()? Alternately, if it were in the contract that the same thread that called client#execute called the methods of the HttpCacheStorage interface, one could probably build something more or less awful using thread local values, but that feels really hacky and would unnecessarily constrain the client impl. On Tue, Jul 5, 2016 at 10:39 AM, Jon Moore <j...@apache.org> wrote: > Hi Donald, > > No, you're not missing anything--there isn't an obvious way to do what you > want to do based on the way things are currently structured. As a side > note, in addition to the ResponseCachingPolicy that Oleg pointed out, there > is also a CacheableRequestPolicy: > > > https://hc.apache.org/httpcomponents-client-4.5.x/httpclient-cache/xref/org/apache/http/impl/client/cache/CacheableRequestPolicy.html > > Whether a response can be served from cache depends on properties both of > the request as well as the response. > > You haven't mentioned it, but your higher-level cache will also want to > look for cache validators like Etag or Last-Modified to make sure your > parsed cache objects correspond to the responses you are getting from the > CachingExec. > > In general, though, you are not the first person to ask about this, and I > think we haven't had a good answer for how to structure this in the client. > If you have some ideas, we would welcome hearing about them. > > Thanks, > Jon > > On Mon, Jul 4, 2016 at 1:53 PM, Donald Ball <donald.b...@gmail.com> wrote: > > > 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 <ol...@apache.org> > > 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: httpclient-users-unsubscr...@hc.apache.org > > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > > > > >
