On 18/06/2014 10:32 p.m., FredB wrote: > >> This is way strange, especially since gmail is in https, which means >> that even if it wanted, squid could not see the traffic nor, >> obviously, cache. >> What do you see in access.log? >> >> >> -- >> kinkie >> > > > In my case nothing special, because this is no related with the cache > I think there are two points, the number of users behind the same address (for me thousands) and something in the request from Squid > Like a kind of confusion from google about ident, I had also the same problem with orange.fr (French isp) > > The problem was related with igoogle, a quick workaround was to denied google.com/ig, but as I said the problem seems gone now The "request" from Squid to upstream in the case of normal HTTPS is a TCP SYN packet. Everything inside the TCP tunnel is strictly between the end-client and server. There are only potentially two relevant details: 1) older versions of Squid would not relay TCP bytes the client sent directly after the CONNECT and before receiving a 200 OK response. That is now fixed in the latest 3.4+ releases. 2) since all this traffic is relayed through Squid it may occur that the machine runs out of TCP sockets. HTTPS removes all proxying optimizations from the protocol, including the major benefit of multiplexing several clients into each TCP connection. Amos
