Re: [squid-users] parseHTTPRequest problem with SQUID3

> I've just rolled back a failed Squid migration from 2.6 to 3.0, and I'm
> looking for reasons why it failed. I have been successfully using the
> latest Squid 2.6 to http-accel a pool of backend web servers, with a
> load-balancer in front to direct traffic.
>
> The load-balancer hits the squid server with a health check, i.e. GET
> /mgmt/alive and expects an HTTP 200, before allowing it to have traffic.
> When I turned up Squid3, all health checks failed...showing the
> following in access.log:
>
> 1226355682.853 0 <ip_of_load-balancer> NONE/400 1931 GET
> http://cached.whatever.com/ps/management/alive - NONE/- text/html
> 1226355684.875 0 <ip_of_load-balancer> NONE/400 1931 GET
> http://cached.whatever.com/ps/management/alive - NONE/- text/html
> 1226355687.905 0 <ip_of_load-balancer> NONE/400 1931 GET
> http://cached.whatever.com/ps/management/alive - NONE/- text/html
>
> After some troubleshooting and turning debug_options up, it appears that
> perhaps it's the request done without a hostname that's the problem,
> because I see 'parseHttpRequest: Missing HTTP identifier' in cache.log
> with debug_options set to ALL,3.

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.

> I know
> from packet captures that my load-balancer literally connects to the
> squid server on port 80 and does a GET /mgmt/alive (not GET
> http://cached.whatever.com/mgmt/alive)
>
> Here are the relevant portions of my config:
>
> http_port 80 accel defaultsite=cached.whatever.com vhost
> cache_dir null /tmp
>
> cache_peer 1.1.1.1 parent 80 0 no-query no-digest originserver
> name=Cached-Whatever
> cache_peer_domain Cached-Whatever cached.whatever.com
>
> 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.

> 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.

> http_access deny all
> http_reply_access allow all
>
> access_log /var/log/squid/access.log squid !HealthChecks
> visible_hostname cached.whatever.com
> unique_hostname squid03
>

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
Received on Tue Nov 11 2008 - 01:08:41 MST