[
https://issues.apache.org/jira/browse/HTTPCLIENT-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970218#action_12970218
]
Michajlo Matijkiw commented on HTTPCLIENT-1032:
-----------------------------------------------
With this change do you think it would be possible to also have cache entries
self identify (ie: adding HttpCacheEntry#getURI()). Under the current system
there is a one to one mapping of variant URI to cache entry, but it seems the
proposed change would make it many to one. I had run into this situation while
developing the stale-while-revalidate patch, which uses the variant URI to
uniquely identify a cache entry. The change wouldn't necessarily break this
patch (assuming it is commited), but could cause unnecessary revalidations.
If this is too much trouble I am sure there will be other ways to derive the
unique key an entry is stored under, it just might require some repetition.
Any thoughts?
- Michajlo
> 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: [email protected]
For additional commands, e-mail: [email protected]
