]> git.ipfire.org Git - thirdparty/squid.git/commit - src/Transients.cc
Bug 5051: Some collapsed revalidation responses never expire (#652)
authorDrDaveD <2129743+DrDaveD@users.noreply.github.com>
Tue, 23 Jun 2020 18:41:15 +0000 (18:41 +0000)
committerSquid Anubis <squid-anubis@squid-cache.org>
Wed, 24 Jun 2020 17:19:17 +0000 (17:19 +0000)
commit6c8cbe63cca3f3496104a625039cf6e4c0493d40
treee87415ce0b8d009b905cabb0e1aa91d4d4a8553b
parent44e802f4cbf3534291c016023b91f23d73584a73
Bug 5051: Some collapsed revalidation responses never expire (#652)

Since negative caching support was repaired in master commit 91870bf, it
has been found to last indefinitely when cache revalidation happens.

New revalidation requests were collapsing on a negatively cached
response forever because handleIMS() logic does not validate response
freshness (still assuming that the reply came in response to the current
request even though that assumption could be false since collapsed
revalidation support was added in master commit 1a210de).

Clearing the ENTRY_REQUIRES_COLLAPSING flag when hitting the negatively
cached collapsed revalidaiton response for the first time works around
this "lack of freshness check" problem. The same solution existed in the
official code for positive responses. However, this solution is partial
and unreliable because there is no guarantee that the clearing code will
be reached (and reached while the cached response is still fresh).

Also added additional partial protections against collapsing on entries
abandoned by their writers, including idle hittingRequiresCollapsing()
StoreEntry objects.

Also fixed a tiny race condition missed in master commit d1d3b4d which
addressed a much bigger (and more frequent) problem. I am not aware of
any real-world cases where this race condition surfaced, but they would
probably manifest in unwarranted failures to collapse.
src/Transients.cc
src/client_side_reply.cc
src/store/Controller.cc
src/store/Controller.h