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

Not fully 1.1, but from (0.9 + 1.0) to fully 1.0 + partial 1.1. Which is
weird because 2.6 went almost fully 1.0 as well quite a while back.

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

always_direct prevents the requests going through peers. Nothing more.
if the domain itself resolves to allow direct requests its okay, but
accelerators should be setup so the domain resolves to Squid which can
cause issues.

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

Yes, to prevent storing them use 'cache deny HealthChecks'.
To prevent logging use 'access_log ... !HealthChecks'

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

Okay. Should have worked the same in 3.x. see my last comment.

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

Okay. That confirms my idea that the HealthChecks request is missing the '
HTTP/1.0' part of the request string. The first line of every valid
accelerated request should look something like this:
  "GET /mgmt/alive HTTP/1.0\n"

Amos
Received on Tue Nov 11 2008 - 02:24:35 MST