[
https://issues.apache.org/jira/browse/HTTPCLIENT-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969807#action_12969807
]
Jon Moore commented on HTTPCLIENT-1032:
---------------------------------------
I think this is related to the way we store and manage variants. Right now, we
create a cache key for a variant based on the varying headers from the original
request, and then store these cache keys on the "parent" entry. I think this
combines two items which should be separated:
1. which cache entries are variants of a parent entry
2. which variant should be used for a particular set of request headers
I think this might be as simple as turning the Set<String> "variantURIs" on the
parent cache entry into a Map<String,String> that maps request header values
(using the scheme we currently use to generate the variantURI cache keys) to
particular cache locations. Thus in the example above, rather than storing a
new variant entry, we should simply "point" requests with "User-Agent: agent2"
to the cache entry for the "agent1" response.
Thoughts?
> cache revalidation of variants does not update original variant entry
> ---------------------------------------------------------------------
>
> Key: HTTPCLIENT-1032
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1032
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: Cache
> Affects Versions: 4.1 Beta1
> Reporter: Jon Moore
> Priority: Minor
> Attachments: variant-entry-update-test.patch
>
>
> When the cache stories multiple variant entries due to Vary headers in
> responses, the cache correctly sends a conditional request containing the
> etags of any existing variants on a "variant miss" (incoming request does not
> match the request variants already cached). In addition, when it receives a
> 304 response, it correctly returns the indicated variant to the request that
> causes the variant miss. However, it does not update the pre-existing variant
> cache entry as recommended by RFC 2616.
> For example:
> request 1, User-Agent: agent1 results in a 200 OK with Etag: etag1 and Vary:
> User-Agent.
> request 2, User-Agent: agent2 causes an If-None-Match to the origin; if it
> returns 304 Not Modified with Etag: etag1
> request 3, User-Agent: agent1 results in a 200 OK but gets the (outdated)
> entry that resulted from request 1
> in other words, the origin response from request 2 does not update the
> variant for "agent1".
> This does not cause incorrect behavior (this is a SHOULD) but does miss out
> on some caching opportunities here.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
