Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
MIME-Version: 1.0
In-Reply-To: <1371314773.11582.10.camel@ubuntu>
References: <1371301229.11582.2.camel@ubuntu>
	<1371305885756.a47f6dc3@Nodemailer>
	<1371314773.11582.10.camel@ubuntu>
Date: Wed, 19 Jun 2013 07:02:41 -0400
Message-ID: 
 <CAMHjJ=RO1KpL+dw53gkTWL6rH5RJ6PWBdjY8nK-zW6wawac17w@mail.gmail.com>
Subject: Re: Caching in http-core?
From: Jon Moore <jonm@apache.org>
To: HttpClient User Discussion <httpclient-users@hc.apache.org>
Content-Type: multipart/alternative; boundary=20cf307f3082b81a4104df7fc45b

--20cf307f3082b81a4104df7fc45b
Content-Type: text/plain; charset=ISO-8859-1

> 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

--20cf307f3082b81a4104df7fc45b--