jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <>
Subject Re: Caching of http responses with Vary header
Date Sun, 18 Jun 2017 17:26:58 GMT
Am 15.06.2017 um 22:23 schrieb Andrey Pokhilko:
> Hi,
> Yes, we had this issue addressed in
> but in very
> "specific" way - by disabling caching for pages that have Vary header.
> Good to have this addressed, I'm glad to join the effort of fixing it,
> if needed, just let me know.
That was the simple fix, but it seems the need for a more complex 
solution has come :(

> IMO, there should be way to improve Vary header handling without much
> overhead. For example, make cache items to have several keys for same
> content, using header value as part of the key. I think it's something
> like you describing.
One problem I see, is that the vary header has to be checked after the 
lookup in the cache, as we can't know it beforehand.
Another problem is that the headers of the request have not be filled, 
when the request (url) is checked for existence in the cache.

So for now I am thinking to change the CacheEntry to be a multi-valued 
entry, that has a sub entry for each vary-header value.

That would lead to a simple lookup (by url) and a check whether a (some) 
vary header exists. If vary header exists, they would have to be 
compared with the headers of the requests (which we don't have, yet) and 
the correct entry could be given back.

On insertion into the cache, we would have to lookup the url in the 
cache and modify the entry and (re-)insert it into the cache.

But I fear -- apart from the more complex algorithm -- that this would 
be even less thread safe than the current version.

The current version doesn't need to be thread safe, when each thread has 
it's own CacheManager. Problems could arise, when they are shared, for 
example by using AsyncSampler.

> Regarding inconsistencies we have 2 ways, one is to be strict
> RFC-conforming, another is to be more browser compliant (browsers
> sometimes forgive RFC non-conformance). I think starting with RFC
> support is good, at least 80/20 solution.

> IMO http/2 has to be addressed separately, 'cause it raises much larger
> architecture questions.

> Andrey Pokhilko
> On 06/15/2017 12:46 PM, Felix Schumacher wrote:
>> Hi all,
>> we currently have one issue
>> ( asking for
>> caching of http responses with a "Vary" header. And I think we had one
>> question about it recently on one of the mailing lists.
>> If we want to support such a feature, we would have to place the call
>> for CacheManager#inCache after we filled the request with all headers.
>> At the moment we get the url, only.
>> The cache would have to be changed to support multiple responses
>> (depending on the Vary header).
>> What happens when a server responds inconsistently with a Vary header
>> (includes it sometimes for a url and leaves it off sometimes)?
>> What are your thoughts on the problems?
>> We probably should also look at httpclient 5 with respect to http/2,
>> as I think it will influence the cache manager, too.
>> Regards,
>>   Felix

View raw message