On 11/08/2016 11:44 a.m., erdosain9 wrote: > Thanks!it works!!!but........... have this strange behavior in > access.log1470835274.046 896 192.168.1.172 NONE/200 0 CONNECT > mail.google.com:443 - HIER_DIRECT/172.217.28.229 -1470835274.569 521 > 192.168.1.172 TCP_MISS/204 406 GET https://mail.google.com/mail/gxlu? - > PINNED/2800:3f0:4002:800::2005 -1470835339.166 797 192.168.1.172 NONE/200 > 0 CONNECT www.facebook.com:443 - HIER_DIRECT/31.13.73.36 -1470835339.398 > 228 192.168.1.172 TCP_MISS/200 1995 POST https://www.facebook.com/ajax/bz - > PINNED/2a03:2880:f100:83:face:b00c:0:25de > application/x-javascript1470835490.537 2164 192.168.1.172 NONE/200 0 > CONNECT www.facebook.com:443 - HIER_DIRECT/31.13.85.36 -1470835491.041 > 504 192.168.1.172 TCP_MISS/200 1800 POST https://www.facebook.com/ajax/bz - > PINNED/2a03:2880:f100:83:face:b00c:0:25de application/x-jfirst a *NONE/200 > *when i go to a https web... it works, but what can be that > "none/200"??? Squid represents port-443 interception as a CONNECT request during the time bumping is going on. So that if it fails is can fallback to treating it as an opaque CONNECT tunnel whch can be relayed through peers etc. That also lets you have the chance to perform http_access controls on the CONNECT based on the client presented TCP or TLS details before the TLS server is contacted during bumping. In the same sort of way you would get a chance to block early for port-80 intercepted requests. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
