[
https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045425#comment-13045425
]
Jon Moore commented on HTTPCLIENT-1099:
---------------------------------------
Hi Bart,
Quick clarification on the specific back-end quirk: you said the origin only
sets the Content-Length header when the body is 8K or under; I presume you
meant it only sets it *correctly* at 8K or under. If the body is larger than
that, does the origin leave off the Content-Length header, or does it set one
with an incorrect value?
I'm presuming it's the latter, but if it's the former then you may have
uncovered a bug (check should only apply if a Content-Length header is present).
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: [email protected]
For additional commands, e-mail: [email protected]
