HttpResponseCache on Android

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Query an endpoint that observes cache control headers
2. Query the end point again before timeout
3. Cached content must be returned rather than hit endpoint again

What is the expected output? What do you see instead?
Expected to see cached content, instead I see the client re-query the webservice

What version of the product are you using? On what operating system?
.88

Please provide any additional information below.

Original issue reported on code.google.com by akshayda...@gmail.com on 6 Feb 2013 at 11:58

[GoogleCodeExporter]

I've changed this to an enhancement request. Patches welcome.

Original comment by turboman...@gmail.com on 6 Feb 2013 at 1:58

• Changed state: Accepted
• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

I'd like to help work with this one, but I have a few questions.

Would it be okay if this was only supported on android versions > Android 4.0 
(Ice Cream Sandwich).  

Should this be default functionality? Or should you have to enable this 
feature?  It seems tricky because HttpResponseCache is application wide, not 
per client.

As a temporary, if you are using > Android 4.0, it looks like you could follow 
the steps on the link below to enable this without a change to the library 
while this is discussed.

http://developer.android.com/reference/android/net/http/HttpResponseCache.html

 try {
           File httpCacheDir = new File(context.getCacheDir(), "http");
           long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
           Class.forName("android.net.http.HttpResponseCache")
                   .getMethod("install", File.class, long.class)
                   .invoke(null, httpCacheDir, httpCacheSize);
        catch (Exception httpResponseCacheNotAvailable) {
       }}

Original comment by jsimmo...@gmail.com on 29 Jan 2014 at 3:44

[GoogleCodeExporter]

Perhaps it would be useful to have a method like client.installCache(size) 
which would install the cache as per the code above. Something like 
client.enableHttpResponseCache(false) could set a flag in AbstractHttpClient to 
send the no-cache directive. After the request, the developer could call 
client.enableHttpResponseCache(true) to reset the flag. Or, we could just add 
methods to HttpRequest to allow setting of headers such as Cache-control on a 
per request basis (these methods will be required, anyway, I suspect). In this 
case, the developer using the API would need to use the HttpRequest subclasses 
directly like new HttpGet(...).execute(...) instead of the convenience methods 
get(), post(), etc. OR, we could add an optional argument for cache control to 
each of the http verbs get(), post(), etc., but that could lead to API clutter. 
Better to make the one-off request without cache using new 
HttpGet(...).execute(...), I think.

Original comment by turboman...@gmail.com on 30 Jan 2014 at 8:44