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