Just to follow up on this thread, it turns out I didn't need to add the stale-if-error header. It appears the CachingHttpClient returned the cached response on a backend timeout without that.
thanks sam On Fri, Jun 7, 2013 at 11:21 AM, Sam Perman <[email protected]> wrote: > Ah... cool. My responses happen to be revalidatable so sounds like this > solution is just what I was looking for. > > Thanks! > > > On Fri, Jun 7, 2013 at 11:19 AM, Jon Moore <[email protected]> wrote: > >> On Fri, Jun 7, 2013 at 11:16 AM, Sam Perman <[email protected]> wrote: >> >> > When you say the resource must be revalidatable in the current version, >> > does that mean my resource server must successfully respond with a 304? >> > >> >> No, the origin doesn't have to respond with a 304; a 200 is fine for that. >> In the current implementation, "being revalidatable" just means the cached >> response needs to have either an ETag or Last-Modified header (so that a >> conditional revalidation request can be sent). >> >> I opened a bug against this, since it should also work for any cached >> response, not just revalidatable ones. >> >> https://issues.apache.org/jira/browse/HTTPCLIENT-1368 >> >> Jon >> > >
