]> git.ipfire.org Git - thirdparty/squid.git/commit - src/peer_select.cc
Bug 4864: !Comm::MonitorsRead assertion in maybeReadVirginBody() (#351) M-staged-PR351
authorChristos Tsantilas <christos@chtsanti.net>
Fri, 15 Feb 2019 15:50:45 +0000 (15:50 +0000)
committerSquid Anubis <squid-anubis@squid-cache.org>
Mon, 18 Feb 2019 12:08:47 +0000 (12:08 +0000)
commit3dde9e52be90ec9bef2aac67a22f792a5f5dfdad
tree2eea673ce09504ed84d07350f214104852a15269
parent36c774f7a0f1c8a3ee7cc8cd87110bd75fe34464
Bug 4864: !Comm::MonitorsRead assertion in maybeReadVirginBody() (#351)

This assertion is probably triggered when Squid retries/reforwards
server-first or step2+ bumped connections (after they fail).
Retrying/reforwarding such pinned connections is wrong because the
corresponding client-to-Squid TLS connection was negotiated based on the
now-failed Squid-to-server TLS connection, and there is no mechanism to
ensure that the new Squid-to-server TLS connection will have exactly the
same properties. Squid should forward the error to client instead.

Also fixed peer selection code that could return more than one PINNED
paths with only the first path having the destination of the actual
pinned connection. To reduce the chances of similar future bugs, and to
polish the code, peer selection now returns a nil path to indicate a
PINNED decision. After all, the selection code decides to use a pinned
connection (whatever it is) rather than a specific pinned _destination_.

This is a Measurement Factory project.
src/FwdState.cc
src/FwdState.h
src/PeerSelectState.h
src/client_side.cc
src/client_side.h
src/peer_select.cc
src/tests/stub_client_side.cc
src/tunnel.cc