Thanks for your response > That message means there was no HTTP/1.0 tag on the request line. > Squid begins assuming HTTP/0.9 traffic. > > >> Squid 2.6 handled these fine, and my configuration hasnt changed, so was >> there something introduced in Squid3 that demands a hostname? > > no. Something has to have changed, because I ported my config over as-is (aside from undefining the 'all' acl element, as specified in the release notes) For a minute I thought Squid had gone HTTP/1.1 and I needed my health checks to supply a Host header, but my capture shows the response as: P.......HTTP/1.0.400.Bad.Request..Server:.squid/3.0.STABLE10..Mime-Versi on:.1.0..Date:.Mon,.10.Nov.2008.22:49:53 (+content) >> acl our_site dstdomain cached.whatever.com >> acl Origin-Whatever dst 1.1.1.1 >> acl acceleratedPort port 80 >> acl HealthChecks urlpath_regex mgmt/alive >> always_direct allow HealthChecks > > This forces HealthChecks to take an abnormal path. Try just letting them > go the same way as regular accelerated request. It will be more accurate > to match the health of client requests. I thought always_direct kept requests from being checked against the cache/siblings? I don't want them cached or logged, just proxied from the origin - so keep 'cache deny HealthChecks' and dump the 'always_direct allow HealthChecks'? I actually tried that during my troubleshooting phase, and it didn't seem to change anything, but I would to be using everything properly. >> cache deny HealthChecks >> cache allow Origin-Whatever >> http_access allow Origin-Whatever acceleratedPort > > I'd say the above two lines are the problem. Unless you are juggling DNS > perfectly to make clients resolve the domain as Squid, and squid resolve > the domain as web server, the 'dst' ACL will fail to work properly on > accelerated requests. > The dstdomain our_site should be used here instead. I juggle, yes. The load balancer uses a virtual IP, to which the cached.whatever.com record points to, which pools traffic to my Squid boxes. I use /etc/hosts on the Squid boxes to point cached.whatever.com to an internal virtual IP that pools traffic to my origin servers. This provides the flexibility and redundancy we need for this setup, and this configuration has always worked fine with 2.6. > Try the config fixes above, and if it still fails can you post a complete > byte-wise exact copy of the failing health check headers please? > > Amos I did notice that if I edited my hosts file to point cached.whatever.com to my new squid3 box, and requested http://cached.whatever.com/mgmt/alive, I got my 200 response. However if I telnet'ed to the new squid3 box on port 80, typed 'GET /mgmt/alive' and hit enter twice, I would get that 400. That really leads me to believe that a hostname is required, as opposed to problems with my config. Thanks again for your thoughts on this - Gregori
