hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Moore, Jonathan" <Jonathan_Mo...@Comcast.com>
Subject roadmap for caching module
Date Mon, 27 Sep 2010 18:12:03 GMT
Hi folks,

After an email exchange with Oleg, I wanted to identify a bit of a
roadmap for the caching module in HttpClient 4.1.X. Primarily this is an
exercise to identify all the things we'd like to do as a way to think
about whether the current class design can easily accommodate them or
not. As we are trying to get the 4.1 release through to GA, it will be
good to understand how the public API of the caching module might or
might not change.

At this point, we've gotten the caching module to the point where I
believe we can call it 'HTTP/1.1 conditionally compliant' (implements
all the MUSTs and MUST NOTs from RFC 2616). As such, I think it is
already in a pretty usable and useful state where folks can begin
getting value from it. We have unit tests in the
TestProtocolRequirements that should help guarantee we won't break that
going forward.

As for upcoming work we'd like to do, I think these can be grouped into
a few different sections.

(These are SHOULD/SHOULD NOT statements from RFC 2616, and will move us
toward unconditional compliance and hence greater interoperability.
Eventually we should consider looking through the entire RFC for these
recommendations for a transparent proxy cache, but for the time being
I'll focus on those in the caching section (Section 13) and in the
description for Cache-Control and conditional headers in Section 14).

* send etags of all variants when servicing a 'variant miss' (13.6)
* support If-None-Match and If-Modified-Since for cache hits (14.25,
* support only-if-cached Cache-Control directive (14.9.4)

(These are specified as MAY statements in the RFC).
* support heuristic caching (13.2.2, 13.2.4) including a default
freshness lifetime; this is in JIRA as HTTPCLIENT-990
* support byterange requests and partial responses (3.12, 10.2.7,
13.5.4, 14.16, 14.27, 14.35)

* support RFC 5861 (stale-while-revalidate and stale-on-error); this is
in JIRA already as HTTPCLIENT-975

* request collapsing: if a request comes in for a resource that is
currently being revalidated, wait for the result of the other
revalidation rather than sending another revalidation downstream

We're actually planning to get to some of the "PROTOCOL RECOMMENDATIONS"
section shortly. RFC 5861 and request collapsing will be interesting as
they will introduce some asynchrony of operation and hence more
synchronization trickery, although I think everything else can be
relatively straightforwardly accommodated in the current design.

Do folks have opinions as to relative priority? I think I've laid them
out roughly "most desirable" to "least desirable", with the exception of
the byterange/partial response support, which I would actually put last
in priority order (I don't think this is commonly used and adds quite a
bit of complexity, so it doesn't have a lot of bang for the buck).


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

View raw message