I do have a webserver hosting the pac file. I set the default site to be that webserver. I do not get it to work. I followed this manual: http://wiki.squid-cache.org/SquidFaq/ReverseProxy On Tue, Dec 9, 2008 at 4:26 PM, Dean Weimer <dweimer@xxxxxxxxxxxx> wrote: > You might try configuring squid as a reverse proxy for a web server actually hosting your proxy.pac file, I have never tried this, but I think it would work. > > Thanks, > Dean Weimer > Network Administrator > Orscheln Management Co > > -----Original Message----- > From: Jan Welker [mailto:jan.welker@xxxxxxxxx] > Sent: Tuesday, December 09, 2008 8:04 AM > To: squid-users@xxxxxxxxxxxxxxx > Subject: Netscape to Squid conversion Issues > > 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 > > 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. > > Any insight would be greatly appreciated. > > Jan >
