hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michajlo Matijkiw (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-1032) cache revalidation of variants does not update original variant entry
Date Fri, 10 Dec 2010 16:29:04 GMT

    [ 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


Mime
View raw message