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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
