On Fri, 5 Nov 2021 at 09:03, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
...
> For your config snippet below
>
> That means usually;
> - helper queries at several points processing each request/transaction,
> - each time those ACLs of yours are *checked*,
> - log outputs when each request finishes, and
> - deny_info URL generation for redirection.
...
> > Squid configuration
> > -------------------
> > #
> > acl connection_id_acl annotate_client conn_id+="%master_xaction/%random"
> > acl has_conn_id_acl note conn_id
> > acl set_conn_id_once_acl any-of has_conn_id_acl connection_id_acl
> > note "" "" set_conn_id_once_acl
> > #
> > logformat log time="%tl" conn_id=%{conn_id}note request_type=%>rm url=%>ru
...
> The problem you have is that the CONNECT request ceases to exist at the
> point it is accepted to be decrypted. The TLS handshake takes time - so
> the conn_id %random value you assigned to that CONNECT is long gone by
> the time the decrypted requests are received. We have several bugs open
> about this situation, but my fix has got stuck with QA rejections from
> other team memmbers.
...
Thanks Amos,
Is it not the case then, that connection_id_acl should be evaluated on connect,
once, and the resulting format code evaluated (expanded), and conn_id "stamped"
on the client connection at this time?
I appreciate that the connect request may dematerialise, but by this
time is there
not a note on the client connection with conn_id="some already-evaluated thing"
which persists until the client connection closes?
What perhaps you mean is that the client connection object does change
on account of the connect
being intercepted, is that what is happening?
Regards,
Jason
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
