You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Bart Robeyns (JIRA)" <ji...@apache.org> on 2011/06/07 12:55:58 UTC
[jira] [Created] (HTTPCLIENT-1099) Overriding Caching Policies
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
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) - which leads me to believe that the tight relationships between client and policies is deliberate. Is this the case, or are you willing to accept a patch that opens up these classes for extending the caching behaviour?
The specific case that lead 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047884#comment-13047884 ]
Oleg Kalnichevski commented on HTTPCLIENT-1099:
-----------------------------------------------
I am with Jon. We should not open up internal APIs without having a compelling and concrete case.
Oleg
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046568#comment-13046568 ]
Jon Moore commented on HTTPCLIENT-1099:
---------------------------------------
Hi Bart,
You're right -- I'll leave this open as a feature request.
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
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Bart Robeyns (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046565#comment-13046565 ]
Bart Robeyns commented on HTTPCLIENT-1099:
------------------------------------------
Jon,
In my view, this issue shouldn't be closed. While the issue that incidentally lead to this ticket has indeed been fixed by HTTPCLIENT-1100, the original request for opening up the policies still stands. If you feel this isn't opportune at the moment, that's ok for me; I'd only like it to be explicitly stated.
Thanks,
Bart
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Bart Robeyns (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045457#comment-13045457 ]
Bart Robeyns commented on HTTPCLIENT-1099:
------------------------------------------
Joh,
I've taken the liberty of not awaiting your answer and already logging it as a bug (https://issues.apache.org/jira/browse/HTTPCLIENT-1100) with patch attached; whether it actually is a bug or not can be discussed within that ticket.
> 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Bart Robeyns (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bart Robeyns updated HTTPCLIENT-1099:
-------------------------------------
Attachment: OpenPolicies.patch
This patch allows to set the Policies on CacheConfig and makes the Policy-classes public.
> 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) - which leads me to believe that the tight relationships between client and policies is deliberate. Is this the case, or are you willing to accept a patch that opens up these classes for extending the caching behaviour?
> The specific case that lead 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Bart Robeyns (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045430#comment-13045430 ]
Bart Robeyns commented on HTTPCLIENT-1099:
------------------------------------------
It actually leaves it off - there's no Content-Length header present. Note that CacheValidityPolicy.getContentLengthValue(HttpCacheEntry) returns the same result (-1) for a non-existing header as for a invalid header-value.
If you consider this a bug I'll make a ticket and attach a patch.
> 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ 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: Future
> 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
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Issue Comment Edited] (HTTPCLIENT-1099) Overriding Caching
Policies
Posted by "Bart Robeyns (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045457#comment-13045457 ]
Bart Robeyns edited comment on HTTPCLIENT-1099 at 6/7/11 2:44 PM:
------------------------------------------------------------------
Jon,
I've taken the liberty of not awaiting your answer and already logging it as a bug (https://issues.apache.org/jira/browse/HTTPCLIENT-1100) with patch attached; whether it actually is a bug or not can be discussed within that ticket.
was (Author: bartrobeyns):
Joh,
I've taken the liberty of not awaiting your answer and already logging it as a bug (https://issues.apache.org/jira/browse/HTTPCLIENT-1100) with patch attached; whether it actually is a bug or not can be discussed within that ticket.
> 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Reopened] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Moore reopened HTTPCLIENT-1099:
-----------------------------------
Immediate bug is fixed, but the request for being able to override/customize caching policies still stands.
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Resolved] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Moore resolved HTTPCLIENT-1099.
-----------------------------------
Resolution: Duplicate
Assignee: Jon Moore
Actually a bug described by HTTPCLIENT-1100
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1099) Overriding Caching Policies
Posted by "Bart Robeyns (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bart Robeyns updated HTTPCLIENT-1099:
-------------------------------------
Description:
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.
was:
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) - which leads me to believe that the tight relationships between client and policies is deliberate. Is this the case, or are you willing to accept a patch that opens up these classes for extending the caching behaviour?
The specific case that lead 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.
> 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org