]> git.ipfire.org Git - thirdparty/squid.git/commit
Removed always-true ClientRequestContext::httpStateIsValid() (#2279)
authorJoshua Rogers <MegaManSec@users.noreply.github.com>
Sat, 1 Nov 2025 22:37:23 +0000 (22:37 +0000)
committerSquid Anubis <squid-anubis@squid-cache.org>
Sun, 2 Nov 2025 02:25:43 +0000 (02:25 +0000)
commit44057fef968505933d7d4334f503447df34c79bf
tree5c2033498b1bc592df81ed80d7ea00e42841baac
parent697fe929849e51d36e1bbdfa432deb35dbdf4526
Removed always-true ClientRequestContext::httpStateIsValid() (#2279)

... and related cbdata checks/comments.

`ClientRequestContext::httpStateIsValid()` always returns true. We
can prove that by contradiction:

* `ClientRequestContext::httpStateIsValid()` return value is
  `cbdataReferenceValid(http)` return value.
* `ClientRequestContext::http` points to a `ClientHttpRequest` object.
* If `cbdataReferenceValid(http)` is false, then the corresponding
  `ClientHttpRequest` object pointed to by `http` has been destructed.
* `ClientHttpRequest` destructor deletes its `calloutContext` data
  member (i.e. `ClientRequestContext`).

Thus, if an `x->httpStateIsValid()` call returns false, then `x` object
has already been deleted, and the call itself was buggy because it was
dereferencing a pointer to a deleted object!

Moreover, `cbdataReferenceValid(nullptr)` is always true, so calling
`httpStateIsValid()` twice for a deleted `ClientHttpRequest` object does
not actually protect the second caller (i.e. does not detect that `http`
is gone) because the first call makes `ClientRequestContext::http` nil,
making `httpStateIsValid()` true again!

None of the above problems actually happen because
`cbdataReferenceValid(http)` is never false inside
`ClientRequestContext::httpStateIsValid()`. By the time it could have
become false, `ClientRequestContext` object itself is already gone.

Also removed a source code comment that falsely claimed that
`ClientRequestContext` callback methods should check whether
`ClientHttpRequest` object is still "valid". In reality,
`ClientRequestContext` methods are not called after `ClientHttpRequest`
object is destructed because they are protected by cbdata guards, and
`ClientHttpRequest` destruction deletes `ClientRequestContext` object,
resulting in those guards skipping any callbacks.

The same comment also incorrectly implied that `ClientHttpRequest` first
becomes "invalid" and then, _after_ the current callback is done,
`ClientHttpRequest` destructor is called. In reality,
`cbdataReferenceValid(x)` becomes false when `delete x` is called and,
hence, when `x` destructor runs.
src/ClientRequestContext.h
src/client_side_request.cc