Remi, Am 29.12.20 um 10:31 schrieb Remi Tricot-Le Breton: > Concerning the vary.vtc, the new behavior can be explained as follows : > Because of the absence of content-encoding in the second response of the > vtc, its encoding is set to "identity", which is accepted by default by > any client not rejecting it explicitely. So when looking into the cache > for a response that might suit a request having an "Accept-Encoding: > first_value" header, this specific one matches.
Which I would say is HAProxy working absolutely correctly with the test testing something incorrect. >> On a related note, I think we're still having an issue that was revealed >> by your discovery of the bug and the fix. Indeed, initially there was >> only the hash for the list of values. The goal was to simply have an >> easy to compare value for a set of known encodings. Now for the known >> ones we have a bitmap. Thus we shouldn't let the known values contribute >> to the hash anymore. >> >> I remain convinced that now that we have the bitmap, we're probably >> deploying too many efforts to allow caching of unknown encodings with >> all the consequences it implies, and that just like in the past we would >> simply not cache when Vary was presented, not caching when an unknown >> encoding is presented would seem perfectly acceptable to me, especially >> given the already wide list of known encodings. And when I see the test >> using "Accept-Encoding: br,gzip,xxx,jdcqiab", this comforts me in this >> idea, because my feeling here is that the client supports two known >> encodings and other ones, if we find an object in the cache using no >> more than these encodings, it can be used, otherwise the object must >> be fetched from the server, and the response should only be cached if >> it uses known encodings. And if the server uses "jdcqiab" as one of >> the encodings I don't care if it results in the object not being cached. > > It would not be that hard to discard responses that have an unknown > encoding but for now the content-encoding of the response is only parsed > when the response has a vary header (it could actually have been limited > to a response that varies on accept-encoding specifically). And > considering that we probably don't want to parse the content-encoding > all the time, responses with an unknown encoding would only be > considered uncacheable when they have a vary, and would be cached when > they don't. I'm totally fine with it if you are too, it would only > require a few lines of explanation in the doc. I'll leave that up to you and just fix the test and send an updated patch to fix *this* specific issue we're currently dealing with. Best regards Tim Düsterhus
