I think it’s not necessary to tell about the benefits of getting rid of advertising and the worst thing - counters (several pieces per page) ... In order for the benefits to be practical and aesthetic, banned images should be replaced with a transparent single-pixel GIF. In the squid-a config, this is done like this:
http_access deny banners
...
deny_info web_server/null.gif banners
In the case of matching the url-a rule from the ACL banners, there is a redirection to a 1-pixel GIF. It seems that everything is simple and this could be stopped. But - what if the web-server in our network is not provided? It happens sometimes. Put only for the distribution of one of the above file? Unsportsmanlike. Imagine a particularly perverted case: the only server we have is a domain controller and squid for NT is installed there (well, by the way, it works!) - not to raise IIS ... Or -
pfsense is used for Internet
access , and web servers are still No, and not foreseen ...
The solution to the problem was prompted to view ftp via squid: the files were indicated by pictures whose address told me that they were issued from the depths of squid-a. A little research and - the solution is ready.
1. Our null.gif we put squid in share / icons
')
2. At the end of the file etc / mime.conf add the line:
null.gif$ image/gif null.gif - image +download +view
3. Let the IP address at which users access squid, is 192.168.1.1, and the standard port is 3128. Then the deny_info directive to squid.conf will look like this:
deny_info 192.168.1.1:3128/squid-internal-static/icons/null.gif banners
You can also redirect to your 1-pixel gif similar files like dumb.gif, 1x1.gif (by writing them in banners), which are still found on the Internet because of the always-
awkward and mediocre preoccupied with cross-browser layout of site builders: we save extra requests to web server.
But we have not done everything yet. It remains the main evil, coming from the counters and advertising - scripts. They often weigh more, in fact, images, load the browser, sometimes cause a long wait for the web page to display, spy on users ... Of course, you can ban everything and immediately on the domains of banner networks, but this way we will get an empty GIF download instead of a script , or - standard HTML page “access denied”, which is also far from a script with tz. syntax - our browsers will be quiet or not (IE) to swear for errors in javascript ... If we don’t want these errors, we’ll have to ban scripts separately. As an option - do it
before the above directive issuing a 1-pixel GIF, but after “http_access deny banners”
First, create an ACL:
acl js urlpath_regex -i \.js(\?.*)?$
(some pests so that their js are not cached and we have to download it every time, add? and different garbage after ...)
Now deny_info itself, going before deny_info against the pictures:
deny_info TCP_RESET banners js
(deny_info always looks at the last ACL!)
Everything, we reload the config and rejoice in the "washed", without ads, quickly opening pages.