RE: [squid-users] parseHTTPRequest problem with SQUID3

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