]> git.ipfire.org Git - thirdparty/squid.git/commit - src/store_digest.cc
Do not overwrite caching bans (#1189)
authorAlex Rousskov <rousskov@measurement-factory.com>
Thu, 8 Dec 2022 08:25:44 +0000 (08:25 +0000)
committerSquid Anubis <squid-anubis@squid-cache.org>
Thu, 8 Dec 2022 21:44:43 +0000 (21:44 +0000)
commitaeeff7fd728b8d53a8091fe0ae8d4fd9c3488dae
treeedcd78af70d29a3ca3678abe1bc83c55dd9b984a
parent41b1056534b394943beb75ae3233fbe0da1a9c7f
Do not overwrite caching bans (#1189)

To ban caching, Squid made RequestFlags::cachable false in several
places (e.g., when a "cache deny" rule matched). To permit caching,
Squid also made the flag true in several places (e.g., when
maybeCacheable() was true). That combination worked as intended only
when the cachable=false veto always came after all the cachable=true
support votes. The code did not (and should not) enforce such a
complicated/fragile timing invariant.

Squid now correctly honors caching bans regardless of the updates order.

This change addresses an old XXX, but we are not aware of any specific
bugs fixed by this change. The primary purpose of this change is to make
the existing baseline ban-honoring functionality easy to maintain.

Also reduced code duplication across cachable=false,noCache=true code.
src/RequestFlags.cc
src/RequestFlags.h
src/base/Makefile.am
src/base/SupportOrVeto.h [new file with mode: 0644]
src/client_side_request.cc
src/http.cc
src/peer_digest.cc
src/servers/FtpServer.cc
src/store_digest.cc
src/tests/testRock.cc
src/tests/testUfs.cc