]> git.ipfire.org Git - thirdparty/squid.git/commit
Bug 4946: client_side_request.cc: "request != newRequest" (#1000)
authorAlex Rousskov <rousskov@measurement-factory.com>
Sat, 19 Mar 2022 21:05:32 +0000 (21:05 +0000)
committerSquid Anubis <squid-anubis@squid-cache.org>
Mon, 21 Mar 2022 21:09:35 +0000 (21:09 +0000)
commit05add813e4baef0d8640a871c53d2fa5ef2a6ffb
treea5b88f262b9fc8048941a78a70d44f4f029f5bf9
parent7801cce90cb6fa3c9ea8c05b5ba00678d1930380
Bug 4946: client_side_request.cc: "request != newRequest" (#1000)

... assertion when preceded by the following error message:

    ERROR: Inconsistent service method ... in dynamic adaptation chain

The assertion is triggered by the following chain of events. During
SslBump step1, a REQMOD adaptation service returns a dynamic
(X-Next-Services) plan containing a RESPMOD service P. Then, during
SslBump step2 (after obtaining TLS client SNI):

* Adaptation::AccessCheck::start() discovers P in the "future services"
  storage (Adaptation::History::theFutureServices) and returns it.

* The adaptation routing code correctly concludes that P is not
  applicable to the current vectoring point, logs the above ERROR, and
  returns the untouched virgin message object to the adaptation
  initiator. See thePlan.exhausted() in Adaptation::Iterator::step().

* ClientHttpRequest asserts because it expects a new message object.

Fixed Adaptation::AccessCheck code no longer assumes that it cannot be
activated twice for the same vectoring point. It leaves services
applicable to future vectoring points in theFutureServices instead of
always suggesting them for the current vectoring point.

TODO: We can and should optimize adaptation requesting code to stop
requiring a new message object when no adaptation is necessary, but that
change is difficult (we tried!) and independent from the bug fixed here.
src/adaptation/AccessCheck.cc
src/adaptation/DynamicGroupCfg.h
src/adaptation/History.cc
src/adaptation/History.h
src/adaptation/ServiceFilter.cc
src/adaptation/ServiceFilter.h