Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Message-ID: <14695593.138031284278973256.JavaMail.jira@thor>
Date: Sun, 12 Sep 2010 04:09:33 -0400 (EDT)
From: "Oleg Kalnichevski (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Subject: [jira] Commented: (HTTPCLIENT-994) cache does not allow client to
 override origin-specified freshness using max-stale
In-Reply-To: <4374395.135781284239973307.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Oleg Kalnichevski commented on HTTPCLIENT-994:
----------------------------------------------

Jon

What is the benefit of moving protocol specific logic back to the HttpCacheEntry? Presently HttpCacheEntry is just a simple bean class that carries state information about a cache entry. One can apply different strategies to determine whether or not the entry is fresh. What do we have to gain by mixing state and protocol logic in one class?

Oleg

> cache does not allow client to override origin-specified freshness using max-stale
> ----------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-994
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-994
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: Cache
>    Affects Versions: 4.1 Alpha2
>            Reporter: Jonathan Moore
>         Attachments: max-stale.patch
>
>
> According to the RFC, the default freshness lifetime is supposed to be the LEAST restrictive of that specified by the origin, the client, and the cache. Right now, a client can't use 'max-stale' to relax the freshness constraints to get a cache hit without validation occuring first.

-- 
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