Thanks for your help. It got me closer. My current config looks like this: http_port 8080 transparent cache_peer localhost parent 80 0 no-query originserver name=pac acl pac dstdomain proxy.company.com 192.168.0.10 cache_peer_access pac allow pac never_direct allow pac 192.168.0.10 is the ip of proxy.company.com. It still does not work. The webserver hosting the pac file works fine. I checked that by browsing the pac file. Am I to stupid? Thanks, On Tue, Dec 9, 2008 at 10:53 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > Jan Welker wrote: >> >> Here's a situation we're facing and I'm curious if anyone has some >> insight into how we might approach this problem. >> >> We currently have approximately pcs, a very large portion of which >> are configured in one of two ways. >> >> A. Netscape browsers with manual proxy servers set up for http and >> https as proxy.host.net:8080 >> B. Netscape browsers with automatic proxy configuration with URL setup >> as proxy.host.net:8080 (note they're the same). >> >> This setup runs fine when pointing to the netscape admin-server/proxy >> server configuration. >> >> The problem I'm having is when I point one of the "automatic" >> configured pcs to one of the boxes running SQUID. At startup, the user >> receives a message saying the automatic configuration has failed and >> on the squid server I see the following access.log entry. >> >> 10.49.0.145 - - [30/Apr/2001:16:28:40 -0400] "GET / HTTP/0.0" 400 1094 >> NONE:NONE > > That is a transparently intercepted request. But your squid.conf does not > appear to include any "http_port ... transparent". > > If you are going the PAC route you will need to remove the NAT capture of > these requests. > >> >> From the docs, it's clear that I need to provide a proxy.pac file >> telling the users what their automatic configuration should be. The >> problem I'm having is how to provide this info and provide >> filtering/caching all from the same port? >> >> Having all the users change their configuration to point to another >> port or host isn't an attractive option (120+ sites, 6000 pcs likely >> to be touched). If I must do that, I'd much prefer to cut over to >> transparent proxying so we don't face this problem again in the future >> and it's trivial for the end users to reconfigure. > > If you take the NAT transparent interception route you WILL face this again > when migrating away from IPv4. DNS based WPAD/PAC is expected to keep going. > > > Amos > -- > Please be using > Current Stable Squid 2.7.STABLE5 or 3.0.STABLE10 > Current Beta Squid 3.1.0.3 or 3.0.STABLE11-RC1 >
