Alex Rousskov wrote:
On Thu, 2008-12-11 at 21:11 +0100, Henrik Nordstrom wrote:
tor 2008-12-11 klockan 12:53 -0700 skrev Alex Rousskov:
Would removing the requirement open more doors for malicious attacks via
"looking like normal" URLs? For example, is it easier for somebody with
local access to change the name resolution for "citi" than for
"citi.com"?
I don't see how it's related.
My question is on Squid's requirements on the hostname of the server
where Squid runs, not proxied hostnames.
Ah, I see. We already have a visible host name option for that and it
accepts non-FQDNs, right? I agree that this requirement is rather
idealistic, but I would like to hear why Kinkie would prefer to keep it.
What are we going to do about loops and absolute exchange URLs if the
Squid host name is not known?
Thank you,
Alex.
I propose that we drop this requirement, only warn if we can't figure
out the local hostname FQDN.
The local server FQDN is used for
- Via headers, as a unique identifier. used for loop prevention.
- Absolute URLs pointing to the server. I.e. icons if use of absolute
URLs have been enabled. (default shortnames without host).
- Absolute URLs for digest & netdb exchanges.
netdb may not be much of a problem. I have a re-work in planning to
cope with IPv6. Should be easy to integrate a URI alteration during that
upgrade.
For peer exchanges it may be a better idea to generate the URI based on
the peer IP:port/path than a FQDN/path.
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
