[
https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139730#comment-15139730
]
Christopher Bradford commented on HTTPCLIENT-1099:
--------------------------------------------------
Recently I have been working on an application where all responses should be
cached. The service being pulled returns the header {{Cache-Control: private,
no-cache="Set-Cookie"}} which appears to trigger a {{true}} response from
{{ResponseCachingPolicy.isExplicitlyNonCacheable}}.
Should I be able to implement my own {{ResponseCachingPolicy}} and configure
the {{CacheConfig}} with it? I would happily commit some of my time to refactor
the code to make this possible.
> 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: Jon Moore
> Priority: Minor
> Labels: cache, policy
> Fix For: Future
>
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
