tor 2008-12-11 klockan 13:41 -0700 skrev Alex Rousskov: > Ah, I see. We already have a visible host name option for that and it > accepts non-FQDNs, right?
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? I would argue neither is a real problem. Most uses a reasonably unique server name, even if it's not a FQDN. And in worst case they get false loop detection. Additionally the percentage running into this is most likely less than the number of people setting visible_hostname and copying the same squid.conf to multiple hosts.. But we probably should add a restriction that the unique server name MUST be a FQDN when accelerator mode is enabled no matter how it's derived (squid.conf or system) or things could get a little confusing if both the reverse proxy and some random squid proxy accessing it has the same name (for example squid1) The digest/netdb exchange URLs is a administrative problem. The servername need to match for the exchange to work in the peering relation (or at least be known, we do support multiple names). Requiring that the server name is a FQDN is not by any means a guarantee for this as very many uses another service name than the actual server name. We could also change to send a server request instead of a proxy request in the peering relation (if we don't do that already) in which case the hostname is a non-issue at least in normal proxy setups.. interception or accelerator setups still need exact matches. Regards Henrik
