Am 19.06.2017 um 20:18 schrieb Andrey Pokhilko:
Regarding thread safety I think we have no other option than making it
thread-safe. For example, modern Java has thread-safe collection
classes, so it is quite transparent from our side.
Well, the Cache is a Collections.synchronizedMap, but the access to the
elements might be not of an atomic operation, so we might need to place
broader locked/synchronized blocks.
I did not go deep into details, but from what I understand Vary header
is part of response, so we know which responses are having it. I assume
that server is consistent with Vary header presence, so we can easily
tell when to store extended records.
I think we might have problems getting all the request headers in the
right places as they might be filled in by the http libraries themselves
(like the user-agent).
It is not clear to me what is next step - are you developing it? Let's
have clarity to not overlap effort.
I have done a first step under https://github.com/apache/jmeter/pull/298
Anyway I'm ready to help with reviewing the design/implementation, when
needed.
That would be awesome.
Felix
Andrey Pokhilko
On 06/18/2017 08:47 AM, Felix Schumacher wrote:
Am 15.06.2017 um 22:23 schrieb Andrey Pokhilko:
Hi,
Yes, we had this issue addressed in
https://bz.apache.org/bugzilla/show_bug.cgi?id=58079 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.
Yes.
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.
OK
IMO http/2 has to be addressed separately, 'cause it raises much larger
architecture questions.
OK
Felix
Andrey Pokhilko
On 06/15/2017 12:46 PM, Felix Schumacher wrote:
Hi all,
we currently have one issue
(https://bz.apache.org/bugzilla/show_bug.cgi?id=61176) 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
