]> git.ipfire.org Git - thirdparty/squid.git/commit
Bug 5030: Negative responses are never cached (#566)
authorDrDaveD <2129743+DrDaveD@users.noreply.github.com>
Wed, 18 Mar 2020 17:34:45 +0000 (17:34 +0000)
committerAmos Jeffries <yadij@users.noreply.github.com>
Sat, 28 Mar 2020 07:35:25 +0000 (20:35 +1300)
commit152d821f07c9ac8f50d8f5f4743679a0ae439c80
tree859d470c300e670011747f0223b0c1c8eb34780d
parentf69293bf12dc805b845bd9c7c0e604a0da409d29
Bug 5030: Negative responses are never cached (#566)

Negative caching was blocked by checkCachable().

Since 3e98df2, Squid cached ENTRY_NEGCACHED entries in memory cache
only. Back then, storeCheckSwapable() prevented what later became
ENTRY_NEGCACHED entries from going to disk. The design was obscured by
8350fe9 that renamed storeCheckSwapable() to storeCheckCachable().

Commit 97754f5 violated that (obscured) design by adding a
checkCachable() call to StoreEntry::memoryCachable(), effectively
blocking ENTRY_NEGCACHED entries from the memory cache as well. That
call should have been added, but checkCachable() should not have denied
caching rights to ENTRY_NEGCACHED -- the corresponding check should have
been moved into StoreEntry::mayStartSwapOut().

By removing ENTRY_NEGCACHED from checkCachable(), we now allow
ENTRY_NEGCACHED entries into both memory and disk caches, subject to all
the other checks. We allow ENTRY_NEGCACHED to be cached on disk because
negative responses are fundamentally no different than positive ones:
HTTP allows caching of 4xx and 5xx responses expiring in the future.
Hopefully, the increased disk cache traffic will not be a problem.
src/store.cc