[squid-users] extract http headers from CONNECT / bumped ssl?

[Amos Jeffries]

On 25/08/17 15:37, Alex Rousskov wrote:
> On 08/24/2017 06:31 PM, Aaron Turner wrote:
> 
>> Actually, looks like I was misunderstanding the access.log, it was working:
>>
>> 1503620688.280      0 10.93.3.85 TAG_NONE/200 0 CONNECT synfin.net:443
>> - HIER_NONE/- - ip_index=0,client=-
>> 1503620689.241    947 10.93.3.85 TCP_MISS/200 57810 GET
>> https://synfin.net/sock_stream/ - HIER_DIRECT/45.79.73.39 text/html
>> ip_index=2,client=foobar1
>>
>> I didn't initially understand that each CONNECT then generates a
>> second entry.
> 
> Each bumped CONNECT tunnel generates one or two CONNECT entries
> (depending on the configuration) followed by zero or more HTTP requests
> found inside the decrypted tunnel.
> 
> 
>>>> external_acl_type client_ip_map_0 %>{My-Custom-Client-Id}
>>>> /usr/lib64/squid/user_loadbalance.py 0 4
> 
>>> That is not your actual external_acl_type line, I hope. The %>h part
>>> looks malformed.
> 
>> Really?  Works and seems to match the instructions indicating "%>{Header}"
> 
> If some instructions imply that omitting "h" from "%>h" is a good idea,
> then I do not recommend following them, even if omiting "h" works.
> 
> The {header-field-name} parameter is fine. It is the missing "h" that I
> would worry about.


FWIW: The non-h forms are only accepted by current Squid-3 for backward 
compatibility and should be producing a high level WARNING on use. That 
has been removed with Squid-4.
  (thanks for the reminder I'm going to have to mention that in the 
release notes).


Please run "squid -k parse" and fix any config problems it highlights. 
This command should be used after upgrades and when editing the config 
to make sure it will actually do what you want in production.


Amos