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

Jon Moore commented on HTTPCLIENT-1099:
---------------------------------------

Hi Bart,

Per Oleg's comment on the users list, we went with a general concept of "keep 
the public API surface as small as possible" in order to allow us more freedom 
to make structural changes to the code without breaking backwards 
compatibility, with the notion that we would add hooks if/when people asked for 
them...and here you are. :)

I'll take a look at this patch over the next couple of days -- thanks for 
submitting it!

Jon

> 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
>            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: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to