Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Mon, 28 Nov 2016 17:34:59 +0000 (UTC)
From: "Jon Moore (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.13023724.1480336487000.379961.1480354499458@Atlassian.JIRA>
In-Reply-To: <JIRA.13023724.1480336487000@Atlassian.JIRA>
References: <JIRA.13023724.1480336487000@Atlassian.JIRA> <JIRA.13023724.1480336487423@arcas>
Subject: [jira] [Comment Edited] (HTTPCLIENT-1789) 200 Response with Vary
 header does not invalidate cached 404 response without
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Mon, 28 Nov 2016 17:35:01 -0000


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1789?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15702356#comment-15702356 ]=20

Jon Moore edited comment on HTTPCLIENT-1789 at 11/28/16 5:34 PM:
-----------------------------------------------------------------

I see what you're saying, and agree this behavior is surprising. I believe =
the issue is that the original {{404}} response did not have a {{Vary}} hea=
der on it; that's not a case I believe we contemplated when writing the cac=
hing module originally.

Let me go back and look at the implementation to see how hard this might be=
 to fix, although if you have a patch or pull request ready to go I'd be ha=
ppy to review that too.

I'm going to adjust the priority of the issue to "Minor"; this is typically=
 how we classify cases where the caching module could cache something but d=
oesn't, or could return a cached entry but doesn't (the rationale being tha=
t the response returned to the client is still a semantically correct one).


was (Author: jonm):
I see what you're saying, and agree this behavior is surprising. I believe =
the issue is that the original `404` response did not have a `Vary` header =
on it; that's not a case I believe we contemplated when writing the caching=
 module originally.

Let me go back and look at the implementation to see how hard this might be=
 to fix, although if you have a patch or pull request ready to go I'd be ha=
ppy to review that too.

I'm going to adjust the priority of the issue to `Minor`; this is typically=
 how we classify cases where the caching module could cache something but d=
oesn't, or could return a cached entry but doesn't (the rationale being tha=
t the response returned to the client is still a semantically correct one).


> 200 Response with Vary header does not invalidate cached 404 response wit=
hout
> -------------------------------------------------------------------------=
----
>
>                 Key: HTTPCLIENT-1789
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-178=
9
>             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.o=
rg/tools/orbit/downloads/drops/R20160520211859/>
>            Reporter: Andreas Sewe
>            Assignee: Jon Moore
>            Priority: Minor
>
> While implementing my own {{HttpCacheStorage}} I noticed the following pr=
oblematic cache revalidation behavior. FYI, this behavior also occurs with =
{{BasicHttpCacheStorage}} (created through {{CachingHttpClients.createMemor=
yBound()}}), 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=3D60}}
> This response is cached under the key {{/something}}. After 60 seconds, a=
nother {{GET}} request is performed and send over the network, as the cache=
d {{404}} response is stale.
> * {{GET /something HTTP/1.1}}
> * {{Accept: application/json}}
> * {{200 OK HTTP/1.1}}
> * {{Vary: Accept}}
> * {{Cache-Control: max-age=3D120}}
> This response is cached under the key {{\{Accept:application/json\}/somet=
hing}} and key {{/something}}=E2=80=99s {{variantMap}} is updated to refer =
to this key. After another 60 seconds, a third {{GET}} request is performed=
 which again performs *network I/O* =E2=80=93 even though it IMHO should no=
t.
> * {{GET /something HTTP/1.1}}
> * {{Accept: application/json}}
> * {{200 OK HTTP/1.1}}
> * {{Vary: Accept}}
> * {{Cache-Control: max-age=3D120}}
> This re-validation occurs because a stale {{404}} response for {{/somethi=
ng}} was cached =E2=80=93 although its {{variantMap}} contains a fresh, sel=
ectable {{200}} response.
> FWIW, [RFC 7234|https://tools.ietf.org/html/rfc7234#page-9] has this to s=
ay 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 f=
or {{/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