You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Jon Moore (JIRA)" <ji...@apache.org> on 2010/12/09 16:35:01 UTC
[jira] Created: (HTTPCLIENT-1032) cache revalidation of variants
does not update original variant entry
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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Closed: (HTTPCLIENT-1032) cache revalidation of variants
does not update original variant entry
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Moore closed HTTPCLIENT-1032.
---------------------------------
> 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
> Assignee: Jon Moore
> Priority: Minor
> Fix For: 4.1.0
>
> 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Updated: (HTTPCLIENT-1032) cache revalidation of variants
does not update original variant entry
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Moore updated HTTPCLIENT-1032:
----------------------------------
Attachment: variant-entry-update-test.patch
Attached is a patch with a unit test that exposes this bug.
> 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Resolved: (HTTPCLIENT-1032) cache revalidation of variants
does not update original variant entry
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Moore resolved HTTPCLIENT-1032.
-----------------------------------
Resolution: Fixed
Fix Version/s: 4.1.0
Assignee: Jon Moore
Issue fixed, and patch with test committed (which now passes).
> 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
> Assignee: Jon Moore
> Priority: Minor
> Fix For: 4.1.0
>
> 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1032) cache revalidation of variants
does not update original variant entry
Posted by "Michajlo Matijkiw (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1032) cache revalidation of variants
does not update original variant entry
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969978#action_12969978 ]
Oleg Kalnichevski commented on HTTPCLIENT-1032:
-----------------------------------------------
Jon,
Can this be done without breaking API compatibility?
Oleg
> 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1032) cache revalidation of variants
does not update original variant entry
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1032) cache revalidation of variants
does not update original variant entry
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970145#action_12970145 ]
Oleg Kalnichevski commented on HTTPCLIENT-1032:
-----------------------------------------------
That's perfectly all right. Go for it.
Oleg
> 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1032) cache revalidation of variants
does not update original variant entry
Posted by "Jon Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970142#action_12970142 ]
Jon Moore commented on HTTPCLIENT-1032:
---------------------------------------
Oleg,
I'm in the process of figuring that out by creating a patch that fixes it. :) My suspicion is that we can do this without breaking API compatibility, although it might mean keeping around methods that don't get used by the main implementation anymore. For example, HttpCacheEntry#getVariants() that just returns a Set will probably be deprecated (although will still work) and we'll be using HttpCacheEntry#getVariantMap() instead going forward.
Jon
> 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org