On 28/08/2015 5:27 p.m., Dan Charlesworth wrote: > I’m trying to figure out if there’s a way to avoid those 0 byte > “peeked” requests being processed by the rest of our external ACLs > etc. by allowing them early on in the transaction. > > Unfortunately there doesn’t seem to be a way to target just those > ones with http_access—the TAG_NONE isn’t an actual method and and > there’s no ACL for the bump mode—without also targeting the spliced > ones. If your helpers logic cant handle CONNECT method requests then you should be using the default configs CONNECT acl definition to skip them. The synthetic ones are just what regular explicit-proxy HTTP would actually have at that point had HTTP been the used properly instead of interception or SSL-Bump. For intercepted port 443 traffic the synthetic/fake CONNECT requests should match something like this: acl portA myportname the-https_port-name acl hasUA req_header User-Agent .+ acl syntheticCONNECT all-of portA CONNECT hasUA http_access allow syntheticCONNECT ... I have not tested this. All the synthetic CONNECT used by squid are generated the same right now, and can be emulated by a client. So you should use with care with teh above. And definitely try to avoid eliding logs in case one comes from outside that matches. I plan to have the squid User-Agent string added in there when it more convenient. So the above will not work long-term. And a Forwarded header with something to indicate intercept is also an eventual possibility. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
