Robert Shilston wrote:
Hi,
Is there a way to configure Squid or any other HTTP proxy to reject
requests such that browsers then use the next proxy that's been supplied
in their PAC file? It looks like HTTP response 306 would have been
perfect, except that browsers don't implement it.
Firefox and IE seem to hop proxy if the proxy replies with an invalid
HTTP response, but Safari doesn't (it seems to try the primary proxy
server for every request, and fail to the second if the first doesn't
open the connection request). And, it's also a bit nasty to use invalid
protocol responses to trigger legitimate behaviour.
So, can anyone suggest how I can persuade a browser to hop to the next
proxy server?
306 maybe only works for HTTP/1.1, which squid does not yet identify
itself as (because the support is not fully done yet).
There is nothing else official or standard that I know of. But, in fact
the very use of PAC is non-official and non-standard.
If the PAC contains a list of proxies ie:
return "PROXY p1.example.com p2.example.com"
the browser is supposed to attempt to use each in turn until one succeeds.
The proxy may be able to then cause the browser to do that by reading
the request enough to identify that its not to serve it. Then abruptly
abort the connection sockets without any response.
For the record; Safari has a number of problems with web traffic in
general. It's a webmasters nightmare of non-standard behavours, second
only to IE in my recent experiences.
If you're wondering why I want to do this, it's because the primary
proxy server will perform some form of non-critical authentication /
user validation, and the second proxy server is DIRECT. So, once the
user is validated, the server would hand them off to run freely directly
over the internet.
Why bother with such a complicated setup?
You may as well configure both proxies to pass all authenticated users
through. And to authenticate those who are not yet authenticated.
Amos
--
Please use Squid 2.6.STABLE19 or 3.0.STABLE4
