[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