[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806281#comment-17806281
 ] 

Oleg Kalnichevski commented on HTTPCLIENT-1099:
-----------------------------------------------

As of 5.4 one will be able to control the behavior of the caching layer by 
using a custom execution context. At this point one can set request cache 
control directives and interrogate the context to get details of the cache 
operation and its outcome.

In the future we can consider adding pluggable custom strategy interfaces for 
request / response cache suitability decisions but not until there is a strong 
case for such API.

Oleg
{code:java}
final ClassicHttpRequest httpget1 = ClassicRequestBuilder.get()
        .setHttpHost(target)
        .setPath("/")
        .build();

// Use default cache control
final HttpCacheContext context = CacheContextBuilder.create()
        .setCacheControl(RequestCacheControl.DEFAULT)
        .build();

System.out.println("Executing request " + httpget1.getMethod() + " " + 
httpget1.getUri());
httpclient.execute(httpget1, context, response -> {
    System.out.println("----------------------------------------");
    System.out.println(httpget1 + "->" + new StatusLine(response));
    EntityUtils.consume(response.getEntity());
    System.out.println("Cache status: " + context.getCacheResponseStatus());
    System.out.println("Request cache control: " + 
context.getRequestCacheControl());
    System.out.println("Response cache control: " + 
context.getResponseCacheControl());
    final HttpCacheEntry cacheEntry = context.getCacheEntry();
    if (cacheEntry != null) {
        System.out.println("Cache entry resource: " + cacheEntry.getResource());
        System.out.println("Date: " + cacheEntry.getInstant());
        System.out.println("Expires: " + cacheEntry.getExpires());
        System.out.println("Last modified: " + cacheEntry.getLastModified());
    }
    return null;
});

final ClassicHttpRequest httpget2 = ClassicRequestBuilder.get()
        .setHttpHost(target)
        .setPath("/")
        .build();

// Ensure a custom freshness for the cache entry
context.setRequestCacheControl(RequestCacheControl.builder()
        .setMinFresh(100)
        .build());

System.out.println("Executing request " + httpget2.getMethod() + " " + 
httpget2.getUri());
httpclient.execute(httpget2, context, response -> {
    System.out.println("----------------------------------------");
    System.out.println(httpget2 + "->" + new StatusLine(response));
    EntityUtils.consume(response.getEntity());
    System.out.println("Cache status: " + context.getCacheResponseStatus());
    System.out.println("Request cache control: " + 
context.getRequestCacheControl());
    System.out.println("Response cache control: " + 
context.getResponseCacheControl());
    final HttpCacheEntry cacheEntry = context.getCacheEntry();
    if (cacheEntry != null) {
        System.out.println("Cache entry resource: " + cacheEntry.getResource());
        System.out.println("Date: " + cacheEntry.getInstant());
        System.out.println("Expires: " + cacheEntry.getExpires());
        System.out.println("Last modified: " + cacheEntry.getLastModified());
    }
    return null;
});

Thread.sleep(2000);

final ClassicHttpRequest httpget3 = ClassicRequestBuilder.get()
        .setHttpHost(target)
        .setPath("/")
        .build();

// Try to force cache entry re-validation
context.setRequestCacheControl(RequestCacheControl.builder()
        .setMaxAge(0)
        .build());

System.out.println("Executing request " + httpget3.getMethod() + " " + 
httpget3.getUri());
httpclient.execute(httpget3, context, response -> {
    System.out.println("----------------------------------------");
    System.out.println(httpget3 + "->" + new StatusLine(response));
    EntityUtils.consume(response.getEntity());
    System.out.println("Cache status: " + context.getCacheResponseStatus());
    System.out.println("Request cache control: " + 
context.getRequestCacheControl());
    System.out.println("Response cache control: " + 
context.getResponseCacheControl());
    final HttpCacheEntry cacheEntry = context.getCacheEntry();
    if (cacheEntry != null) {
        System.out.println("Cache entry resource: " + cacheEntry.getResource());
        System.out.println("Date: " + cacheEntry.getInstant());
        System.out.println("Expires: " + cacheEntry.getExpires());
        System.out.println("Last modified: " + cacheEntry.getLastModified());
    }
    return null;
});

{code}
 

> Overriding Caching Policies
> ---------------------------
>
>                 Key: HTTPCLIENT-1099
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1099
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpCache
>    Affects Versions: 4.1.1
>            Reporter: Bart Robeyns
>            Assignee: Jonathan Moore
>            Priority: Minor
>              Labels: cache, policy, stuck, volunteers-wanted
>             Fix For: 5.4-alpha2
>
>         Attachments: OpenPolicies.patch
>
>
> It is not possible to alter the behaviour of the CachingHttpClient because 
> the policies defining the behaviour are private and tied directly to specific 
> implementations in the CachingHttpClients constructor. Furthermore, these 
> policies are package private, discouraging reuse and/or extensions.
> Making this possible is easy enough (provide some policy-setters or 
> -constructor-args in CachingHttpClient and make the policy-classes public); 
> the attached patch allows custom Policies, extending the default ones to be 
> set on the CacheConfig class.
> The specific case that led to this question:
> A back-end application only sets its Content-Length header for responses 
> below 8K. This response does get stored in the cache, but when retrieving it 
> from the cache, CacheValidityPolicy.contentLengthHeaderMatchesActualLength 
> checks the Content-Length header with the stored size (to verify whether the 
> cached content is complete). This check fails, causing the cache entry to be 
> deemed unusable. If we were able to provide our own subclassed 
> CacheValidityPolicy, it would be easy to skip the check if the header is 
> missing and thus accomodate this specific back-end quirk.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to