hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Moore (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-990) CachingHttpClient does not return from cache responses having only the public cache-control directive
Date Wed, 08 Sep 2010 13:08:33 GMT

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

Jonathan Moore commented on HTTPCLIENT-990:
-------------------------------------------

Hi Vianney,

Let me start by saying that this is known behavior that is compliant with the RFC (as you
note, caching responses without freshness information is a MAY in the protocol spec, not a
MUST or a SHOULD). As such, this should not be marked as a "bug".

The protocol spec clearly talks about ways to handle these responses; one is by heuristically
estimating a freshness lifetime, usually based on a comparison of the Last-Modified header
with the Date header in the response.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.2
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4

I would suggest re-classifying this issue as an "improvement" titled "allow heuristic freshness
caching" that can be turned on as an optional feature.

Please note that even with this feature, your origin server is not really providing as much
information as it could be. The RFC explicitly suggests that having origin servers correctly
set cache-related headers is preferable to heuristic expiration calculations. In particular,
if your intent is that the response can be completely served from cache, the origin ought
to set either the Expires header or the max-age parameter on Cache-Control. If your intent
is just that the response body be cached but that you will allow revalidation, you need to
include a validator in the response (either ETag or Last-Modified).


> CachingHttpClient does not return from cache responses having only the public cache-control
directive
> -----------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-990
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-990
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: Cache
>    Affects Versions: 4.1 Alpha2
>            Reporter: Vianney Carel
>            Priority: Minor
>         Attachments: debug.log
>
>
> I noticed that the CachingHttpClient behaves strangely when it receives responses with
only the public cache-control directive, e.g.:
> HTTP/1.0 200 OK
> Server: My test server
> Cache-control: public
> Content-Length: 1
> 1
> Using a debugger, I could see that the response is cached. But when the response is queried
from the cache, it is not considered as "fresh".
> According to the HTTP RFC, such responses "may" be cached (I understand it as a "should"
in our case)... but there's no reason to put responses in the cache if we don't use them later
one.
> The "freshness of the response is analysed after the response is queried from the cache,
thanks to:
> CachedResponseSuitabilityChecker#canCachedResponseBeUsed()
> ... calling CacheEntry#isResponseFresh()
> ... returning true if the response date (getCurrentAgeSecs()) is lower than its use-by
date (getFreshnessLifetimeSecs())
> The issue is that getFreshnessLifetimeSecs() returns 0 when there is no max-age directive.
> This could be fixed by replacing the code of CacheEntry#isResponseFresh() by:
>     public boolean isResponseFresh() {
>         final long freshnessLifetime = getFreshnessLifetimeSecs();
>         if (freshnessLifetime == 0) {
>             return true;
>         }
>         return (getCurrentAgeSecs() < getFreshnessLifetimeSecs());
>     }
> But i'm not 100% confident about not producing some bad side-effects...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message