Differences between version 16 and previous revision of SquidNotes.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 16 | Last edited on Monday, August 28, 2006 9:26:37 pm | by CraigBox | Revert |
| Older page: | version 15 | Last edited on Thursday, July 20, 2006 1:26:11 pm | by CraigBox | Revert |
@@ -1,8 +1,7 @@
!!! [Squid] Caching Proxy Server Notes
-----
!!Problem solving
-
!Resolving name problems
Having problems that ~http://brian/wherever/whatever doesn't resolve in Squid? This is caused by Squid running its own DNS resolver, instead of using gethostbyname(3). It pulls the IPs of the name servers out of resolv.conf(5). Add a line like this to your squid.conf:
append_domain .yourdomain.tla
@@ -230,14 +229,13 @@
This can't work. An [excellent post on the topic to the Squid users list|http://www.squid-cache.org/mail-archive/squid-users/200202/0147.html] summarises why:
> HTTP specifies two "authentication required" error codes. One for a HTTP server (401), the other for a HTTP proxy (407). When a browser connects to a server requiring authentication, the server examines the HTTP header supplied in the request. If it includes the correct authentication information (username and password) the request is honoured and the server sends back a return code of 200. If the authentication information is not present in the header, the server responds with a return code of 401. When the browser sees this it pops up the authentication window where you type your username and password. The browser then re-submits the original request this time containing the authentication information it just collected. All future requests to the server will contain the authentication information.
>
-> Proxy authentication is handled in a similar manner. A browser that knows it's using a proxy (in tranparent proxying, this is NOT the case) makes a connection to the proxy and issues an HTTP request. That request can contain proxy authentication information. Note that this is in a different part of the HTTP request to the web server authentication information. If the proxy requires authentication and the proxy-auth HTTP header is empty, the proxy responds with a return code of 407. When the browser receives this it pops up a window asking for the proxy username and password. Once you've typed it in, the browser resubmits the original request this time
-
+> Proxy authentication is handled in a similar manner. A browser that knows it's using a proxy (in tranparent proxying, this is NOT the case) makes a connection to the proxy and issues an HTTP request. That request can contain proxy authentication information. Note that this is in a different part of the HTTP request to the web server authentication information. If the proxy requires authentication and the proxy-auth HTTP header is empty, the proxy responds with a return code of 407. When the browser receives this it pops up a window asking for the proxy username and password. Once you've typed it in, the browser resubmits the original request this time containing the proxy authentication information. All further requests to the proxy will contain the authentication information.
>
> If a browser is not configured to use a proxy, it will quite rightly ignore any return code of 407. Why should it give away your proxy username and password to anyone who asks for it?
> In your case you have browser->transparent proxy->auth proxy. The auth proxy can certainly request authentication of the transparent proxy. The cache_peer config line supports this with the "login=user:password" option. However, all that does is authenticate the proxy with its parent. There is no way to make the transparent proxy authenticate individual users. Even if the 407 sent by the auth proxy, could be passed from transparent proxy to browser (it can't because the transparent proxy traps it) you cannot make the browser respond because as far as it knows, it isn't using a proxy.
> As has been stated many, many times on this list:
> transparency, authentication, pick one.
