hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Sewe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1789) 200 Response with Vary header does not invalidate cached 404 response without
Date Mon, 05 Dec 2016 11:14:59 GMT

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

Andreas Sewe commented on HTTPCLIENT-1789:
------------------------------------------

{quote}
Granted, a new 404 with Vary header should "reset" the cache, so the problem won’t persist
indefinitely (although I haven’t tested this).
{quote}

Unfortunately, the scenario outlined in the initial bug report indeed does persist *indefinitely*.
The stale {{404}} responses causes revalidation whenever {{/something}} is accessed. Even
though stale, it won’t get removed from the cache but simply causes revalidation.

Interestingly, after receiving the {{200}} reponse, the root {{HttpCacheEntry}} in my {{HttpCacheStorage}}
is indeed updated; the new root {{HttpCacheEntry}} does contain a {{variantMap}}, but as {{BasicHttpCache.getCacheEntry}}
checks for variants with {{root.hasVariants()}}, which checks for the {{Vary}} header rather
than for the {{variantMap}} inserted during the recent update, {{BasicHttpCache.getCacheEntry}}
doesn't even _see_ the variants.

To me, this looks like the root cause of the problem: The current code assumes that the root
entry has a {{Vary}} header; if not, no other variants will be accessible, even if present
in the underlying {{HttpCacheStorage}}.

> 200 Response with Vary header does not invalidate cached 404 response without
> -----------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1789
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1789
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpCache
>         Environment: Tested with the org.apache.httpcomponents.httpclient 4.3.6 OSGi
bundle distributed by Eclipse Orbit: <http://download.eclipse.org/tools/orbit/downloads/drops/R20160520211859/>
>            Reporter: Andreas Sewe
>            Assignee: Jon Moore
>            Priority: Minor
>
> While implementing my own {{HttpCacheStorage}} I noticed the following problematic cache
revalidation behavior. FYI, this behavior also occurs with {{BasicHttpCacheStorage}} (created
through {{CachingHttpClients.createMemoryBound()}}), so it is not caused by my {{HttpCacheStorage}}
implementation. Consider this sequence of requests and responses:
> * {{GET /something HTTP/1.1}}
> * {{Accept: application/json}}
> * {{404 Not Found HTTP/1.1}}
> * {{Cache-Control: max-age=60}}
> This response is cached under the key {{/something}}. After 60 seconds, another {{GET}}
request is performed and send over the network, as the cached {{404}} response is stale.
> * {{GET /something HTTP/1.1}}
> * {{Accept: application/json}}
> * {{200 OK HTTP/1.1}}
> * {{Vary: Accept}}
> * {{Cache-Control: max-age=120}}
> This response is cached under the key {{\{Accept:application/json\}/something}} and key
{{/something}}’s {{variantMap}} is updated to refer to this key. After another 60 seconds,
a third {{GET}} request is performed which again performs *network I/O* – even though it
IMHO should not.
> * {{GET /something HTTP/1.1}}
> * {{Accept: application/json}}
> * {{200 OK HTTP/1.1}}
> * {{Vary: Accept}}
> * {{Cache-Control: max-age=120}}
> This re-validation occurs because a stale {{404}} response for {{/something}} was cached
– although its {{variantMap}} contains a fresh, selectable {{200}} response.
> FWIW, [RFC 7234|https://tools.ietf.org/html/rfc7234#page-9] has this to say about the
subject:
> {quote}
>    The stored response with matching selecting header fields is known as
>    the selected response.
>    If multiple selected responses are available (potentially including
>    responses without a Vary header field), the cache will need to choose
>    one to use.  When a selecting header field has a known mechanism for
>    doing so (e.g., qvalues on Accept and similar request header fields),
>    that mechanism MAY be used to select preferred responses; of the
>    remainder, the most recent response (as determined by the Date header
>    field) is used, as per Section 4.
> {quote}
> According to this, the {{200}} response should have been selected, as its {{Date}} is
newer than the {{404}}'s responses. Instead, another request for {{/something}} is send to
the server, even though the most recent cache entry is still fresh.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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


Mime
View raw message