]> git.ipfire.org Git - thirdparty/squid.git/commit - src/icp_v2.cc
Ensure initClient MasterXactions have listening ports (#993)
authorEduard Bagdasaryan <eduard.bagdasaryan@measurement-factory.com>
Wed, 11 May 2022 16:51:10 +0000 (16:51 +0000)
committerSquid Anubis <squid-anubis@squid-cache.org>
Thu, 12 May 2022 19:33:47 +0000 (19:33 +0000)
commitad05b958fa522d73023eebf37dbfbf57829a9507
tree1062c5de924663b6f910ccd3afa128c0d89b5f83
parent5a3b42b18349bf78175811cb0a64dd5c4aeae32d
Ensure initClient MasterXactions have listening ports (#993)

MasterXaction creation code that forgets to supply a port for an
initClient transaction will now be rejected by the compiler.

This safety improvement hit two problems described below.

The TcpAcceptor class was incorrectly creating a MasterXaction object
for FTP DATA connections. We moved MasterXaction creation to TcpAcceptor
callbacks because only they know whether accepting a TCP connection
implies a new master transaction start (it does not for FTP DATA cases).

The Downloader class was implemented to spawn its own MasterXaction
using XactionInitiator info supplied by the download requestor. That
design is incompatible with the new static assertion because each
MasterXaction creator must now hard-code XactionInitiator value for the
assertion to work at _compile_ time. All other contexts naturally
hard-code that value.

We saw two ways to resolve this conflict:

a) Let the download requestor create the MasterXaction object for the
   Downloader. The primary advantage of this (implemented) approach is
   that it allows (future) client request processing code to satisfy
   client requests using Downloader. Such request satisfaction requires
   sharing the master transaction between the client transaction and the
   downloader transaction, and this change enables such sharing. This
   change moves the "Which master transaction does this download belong
   to?" question from the Downloader into download requestors.

b) Move initClient-has-port enforcement (and squidPort) from
   MasterXaction into XactionInitiator. The primary advantage of this
   (not implemented) approach is that it places that enforcement inside
   the type it is meant to police (essentially) -- XactionInitiator.

The two changes are complementary. We did not implement (b) because it
requires significant XactionInitiator redesign, moving _all_ originating
client information from MasterXaction to XactionInitiator (currently
squidPort and tcpClient).
26 files changed:
src/CommCalls.cc
src/CommCalls.h
src/Downloader.cc
src/Downloader.h
src/MasterXaction.h
src/PeerPoolMgr.cc
src/acl/Asn.cc
src/adaptation/ecap/Host.cc
src/adaptation/icap/Xaction.cc
src/client_side.cc
src/client_side_reply.cc
src/comm/TcpAcceptor.cc
src/esi/Include.cc
src/htcp.cc
src/icmp/net_db.cc
src/icp_v2.cc
src/mgr/Inquirer.cc
src/mime.cc
src/neighbors.cc
src/peer_digest.cc
src/security/PeerConnector.cc
src/servers/FtpServer.cc
src/servers/Http1Server.cc
src/servers/forward.h
src/store_digest.cc
src/tests/testHttpRequest.cc