[
https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047191#comment-13047191
]
Jon Moore commented on HTTPCLIENT-1099:
---------------------------------------
My general take on this is that we shouldn't work on opening up the API until
someone has a use case that requires it (in Bart's case, he exposed a bug, so
that doesn't count). I believe that people will have those use cases and that
we should use those to drive increasing the API surface, but that we should
also defer as long as possible--this increases the freedom we have to
restructure the codebase in the meantime. Given that HC is a pretty active
project and we can get releases out relatively quickly, I'm not terribly
worried about having to anticipate future use.
So, if you have a use case where the current implementation doesn't do what you
want and there isn't an easy way around it, please post it here!
> Overriding Caching Policies
> ---------------------------
>
> Key: HTTPCLIENT-1099
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1099
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Affects Versions: 4.1.1
> Reporter: Bart Robeyns
> Assignee: Jon Moore
> Priority: Minor
> Labels: cache, policy
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
