[squid-users] extract http headers from CONNECT / bumped ssl?
Amos Jeffries
squid3 at treenet.co.nz
Sat Aug 26 05:14:51 UTC 2017
On 26/08/17 09:42, Alex Rousskov wrote:
> On 08/25/2017 10:37 AM, Aaron Turner wrote:
>> Followup: I tried %{My-Custom-Client-Id}>h with 3.5.26 and squid
>> errors out. Looking at the 3.5.x docs
>> (http://www.squid-cache.org/Versions/v3/3.5/cfgman/external_acl_type.html),
>> nothing there indicates it supports the logformat method? Looks like
>> that's a 4.0+ feature?
It seems I forgot to do the documentation changes in 3.4 or 3.5 to
follow the code changes in 3.3.
As recompense I shall dedicate some time into adding back-compat code
for Squid-4+ so that it accepts the 3.5 documented syntax. The Squid-2
syntax is not possible to do in the new code. Which IIRC was a big
reason for the slow staged rollout plan, hoping not to need back-compat
here. Sorry for the muckup.
>
> Apparently v3.5 is still using those custom format codes for external
> ACLs (i.e., codes that differ from "standard" logformat codes). I did
> not realize that. Sorry.
>
The custom parser back in Squid-3.3.7 was prepared for logformat codes
when the logformat syntax was only %code{parameters}.
squid -k parse for me with the old options produces:
WARNING: external_acl_type format %{...} is being replaced by
%>ha{...} for %{test}
WARNING: external_acl_type format %>{...} is being replaced by
%>ha{...} for %>{test}
and accepts %>ha{test}
Notice that the old %{...} and %>{...} send the *adapted* request
headers to the helper, not the original client headers. To distinguish
the real client headers from adapted ones you do need the proper
logformat codes in Squid-4+.
Amos
More information about the squid-users
mailing list