[
https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski updated HTTPCLIENT-1099:
------------------------------------------
Fix Version/s: 5.4-alpha2
(was: Stuck)
> 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
