hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-994) cache does not allow client to override origin-specified freshness using max-stale
Date Mon, 13 Sep 2010 09:00:33 GMT

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

Oleg Kalnichevski commented on HTTPCLIENT-994:

> In this case, the methods that got moved to HttpCacheEntry are all essentially properties
of a cache entry; 
> just as a Header can find its HeaderElements for you, now an HttpCacheEntry can tell
you its apparent age 
> (a *defined* property in the RFC)

There would be too way much protocol logic beyond simple parsing operations in the HttpCacheEntry
to my personal liking. RFCs do get superseded with updated versions. You never know what might
happen in the future. If HttpCacheEntry API proves inflexible to meet new requirements, pretty
much the entire caching API will have to be deprecated. 

> Finally, I think the CacheValidityPolicy and HttpCacheEntry as they exist in trunk now
exhibit a few OO "code smells", 
> namely that they are two separate classes that are tightly coupled.

I am not sure I agree. HttpCacheEntry has no dependency on CacheValidityPolicy of what so

> But generally speaking, I think this is as simple as "why have two classes when one will

Because you never know what might happen in the future. I have been maintaining HttpClient
for looooong 7 years and I have had numerous moments when I wished some bits of code had never
been made a part of public API.

If you remain unconvinced I'll commit the patch within a few days.


> 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

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

View raw message