On 13/11/2015 1:02 a.m., Edouard Gaulué wrote: > > In the https case I observe just 1 stream: > CONNECT ad.doubleclick.net:443 HTTP/1.1 > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0) > Gecko/20100101 Firefox/42.0 > Proxy-Connection: keep-alive > Connection: keep-alive > Host: ad.doubleclick.net:443 > > HTTP/1.1 302 Found > Server: squid/3.5.10 > Date: Thu, 12 Nov 2015 10:35:57 GMT > Content-Length: 0 > Location: > https://proxyweb.echoppe.lan/cgi-bin/squidGuard-simple.cgi?clientaddr=192.168.0.74pipo&clientname=192.168.0.74&clientuser=&clientgroup=marine&targetgroup=adv > > X-Cache: MISS from squid > X-Cache-Lookup: MISS from squid:3128 > Via: 1.1 squid (squid/3.5.10) > Connection: keep-alive > > CONNECT ad.doubleclick.net:443 HTTP/1.1 > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0) > Gecko/20100101 Firefox/42.0 > Proxy-Connection: keep-alive > Connection: keep-alive > Host: ad.doubleclick.net:443 > > > All this is between my client and proxy server. > > Why is the browser not taking account of the redirect? Think about *exactly* what is being redirected. CONNECT is a request to setup a blind packet relaying tunnel. > Why is it redoing the same connect? Because its a browser. They do some really weird things when confused. It was told a TCP relay tunnel existed at "https://proxyweb.echoppe.lan/cgi-bin/...";. Thats a pretty weird place for a network socket to exist. > Why is there no trace at all in the proxy logs of this second CONNECT? > Only if it was handled would it be logged. It seems it may have been read in (or maybe not) but definitely not processed for some reason. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
