[
https://issues.apache.org/jira/browse/HTTPCLIENT-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790072#comment-13790072
]
kyle leonhard commented on HTTPCLIENT-1415:
-------------------------------------------
First, thanks for the comprehensive response!
After looking at the spec I agree that the existing implementation is
standards-compliant and works for most use cases. HTTPCLIENT-1384 will address
my issue. I'll be tempted to abuse the content-location or custom headers in
some heinous ways. In the mean time I've side stepped the issue by adding etag
support to the origin server.
On an unrelated note.. I'm digging the new client/cache builders introduced in
4.3. Quite a step forward from the old configuration and initialization
methods.
Here's the relevant section of the spec for anyone reading in the future:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6
------
"If a cache receives a successful response whose Content-Location field matches
that of an existing cache entry for the same Request- ]URI, whose entity-tag
differs from that of the existing entry, and whose Date is more recent than
that of the existing entry, the existing entry SHOULD NOT be returned in
response to future requests and SHOULD be deleted from the cache."
> Cached entry is not flushed when a response contains a content-location
> header without an ETag header field
> -----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1415
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1415
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpCache
> Affects Versions: 4.3.1
> Environment: Windows 7, Tomcat
> Reporter: kyle leonhard
> Fix For: 4.3.2
>
> Attachments: CacheInvalidator.java.patch
>
>
> When a response returns a content-location header, flushLocationCacheEntry is
> invoked on the content-location's URL. flushLocationCacheEntry causes the
> cached entry to be flushed if the entry is older than the response and the
> etags differ.
> However, the response and entry ETags are not considered different if either
> ETag header values are
> null(see:CacheInvalidator.responseAndEntryEtagsDiffer). This causes the
> resource referenced by the response's content-location header to remain
> cached.
> I'm not familiar with the HTTP spec, but the responseAndEntryEtagsDiffer,
> ETag null checks seem iffy.
> The same problem effects 4.2.5 as well.
> **Relevant code
> ***From CacheInvalidator.flushInvalidatedCacheEntries:
> final URL contentLocation = getContentLocationURL(reqURL, response);
> if (contentLocation != null) {
> flushLocationCacheEntry(reqURL, response, contentLocation);
> }
> ***From CacheInvalidator.flushLocationCacheEntry
> if (responseDateOlderThanEntryDate(response, entry)) {
> return;
> }
> if (!responseAndEntryEtagsDiffer(response, entry)) {
> return;
> }
> ***From CacheInvalidator.responseAndEntryEtagsDiffer:
> if (entryEtag == null || responseEtag == null) {
> return false;
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
