Willy, Am 29.12.20 um 07:52 schrieb Willy Tarreau: > Thanks for this, but while your patch looks valid, the regtest fails > for me: > > [...]
Oh, indeed. I only tested the reg-test I modified and forgot to run all the cache tests after finishing up my changes :-( > I don't know if it's the code or the test, but we're having an issue here > it seems. Note that this response has no content-encoding so there might > be something caused by this. I'd say it's the test. For the first request the server responded with an unacceptable `content-encoding`, the third request expects that this unacceptable `content-encoding` is being delivered from the cache. In the real world it might be that this is the only encoding the server knows, but HAProxy as the cache cannot know this and must defer to the server. > 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. Indeed when suggesting to use a bitmap I had in mind that the hash would be fully replaced by the bitmap. > 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. Yes, I agree. Especially since adding new known encodings is easy to do (add a bit, add logic to add that bit) and can easily be backported to stable branches. Best regards Tim Düsterhus
