hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "kyle leonhard (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1415) Cached entry is not flushed when a response contains a content-location header without an ETag header field
Date Wed, 09 Oct 2013 06:24:44 GMT

    [ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message