[
https://issues.apache.org/jira/browse/HTTPCLIENT-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208730#comment-14208730
]
Jon Moore commented on HTTPCLIENT-1579:
---------------------------------------
Hi, do you have an example client/server exchange (including headers) that
illustrates this issue? Even better: do you have a unit test that can
illustrate your specific scenario? Either one would be helpful in diagnosing
the issue. In particular, the caching module does update cache entry headers
when it receives an origin 304 (and there are tests that cover that behavior),
so more detail would be helpful to understand how your scenario is different
from the ones we've contemplated already.
Thanks!
> CacheValidityPolicy does not correctly handle 304 Not Modified freshness
> ------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1579
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1579
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.3.3, 4.3.4, 4.3.5, 4.3.6
> Reporter: Nitin Kumar
>
> When a cached response expires, http cache client correctly makes a new
> request to the http server. When the response is still fresh at the server
> side, the server responds with HTTP/1.1 304 Not Modified and sends in a new
> Expires: header.
> On subsequent request, when the cache entry should be still valid as per the
> time stamp received in the Expires header from the last call,
> CacheValidityPolicy tries to validate the cache entry in the
> isResponseFresh() method and incorrectly marks the the entry as stale.
> The result is that http cache client keeps making new requests to the http
> server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
