RE: [squid-users] parseHTTPRequest problem with SQUID3
So, do I need to file a bug report, so that this can get addressed? Or are the devs already aware? -Original Message- From: Amos Jeffries [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2008 5:56 PM To: Gregori Parker Cc: Amos Jeffries; squid-users@squid-cache.org Subject: RE: [squid-users] parseHTTPRequest problem with SQUID3 Increases in compatibility are in the release notes and ChangeLog The regression in 0.9 support you hit is a bug. Is there any possibility of restoring 0.9 support in Squid3? I can always have my load-balancer format the requests to contain the HTTP/1.0\n, but that seems like a real hidden gotcha for anyone migrating from 2.6 to 3.0 - which is fine, as long as it's called out in the release notes. Yes, it is a bug in both squid and the balancer. Squid is supposed to be able to handle obsolete 0.9 anyway. We have to track it down and fix. But its not to say that the load balancer itself isn't 'broke' for sending 0.9 traffic. Amos
RE: [squid-users] parseHTTPRequest problem with SQUID3
On ons, 2008-11-12 at 13:51 -0800, Gregori Parker wrote: So, do I need to file a bug report, so that this can get addressed? Or are the devs already aware? The devs are aware (or at least both me and Amos), but please file a bug report anyway. Much easier for us to track the issue then. Regards Henrik signature.asc Description: This is a digitally signed message part
RE: [squid-users] parseHTTPRequest problem with SQUID3
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. I wish changes like this were called out in the release notes 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. That was the intention...I don't want Squid checking siblings for healthchecks, so I'll keep the always_direct line in addition to the cache deny. Yes, to prevent storing them use 'cache deny HealthChecks'. To prevent logging use 'access_log ... !HealthChecks' Done. I already had the logging configured as such, just omitted it from my message because it was extraneous to the discussion. 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 Is there any possibility of restoring 0.9 support in Squid3? I can always have my load-balancer format the requests to contain the HTTP/1.0\n, but that seems like a real hidden gotcha for anyone migrating from 2.6 to 3.0 - which is fine, as long as it's called out in the release notes. Thanks
Re: [squid-users] parseHTTPRequest problem with SQUID3
Henrik Nordstrom wrote: On tis, 2008-11-11 at 15:24 +1300, Amos Jeffries wrote: 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. From this discussion it seems Squid-3 no longer accepts the obsolete HTTP/0.9 style requests. Yes it seems that way. Squid-2 do support HTTP/0.9 in accelerator mode, including returning a HTTP/0.9 style response (no headers in either request or response). The code I traced from his reported info showed it warning and continuing on elsewhere. Couldn't easily find the break. But the end result shows it. Amos -- Please be using Current Stable Squid 2.7.STABLE5 or 3.0.STABLE10 Current Beta Squid 3.1.0.2
RE: [squid-users] parseHTTPRequest problem with SQUID3
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. I wish changes like this were called out in the release notes Increases in compatibility are in the release notes and ChangeLog The regression in 0.9 support you hit is a bug. 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. That was the intention...I don't want Squid checking siblings for healthchecks, so I'll keep the always_direct line in addition to the cache deny. Yes, to prevent storing them use 'cache deny HealthChecks'. To prevent logging use 'access_log ... !HealthChecks' Done. I already had the logging configured as such, just omitted it from my message because it was extraneous to the discussion. 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 Is there any possibility of restoring 0.9 support in Squid3? I can always have my load-balancer format the requests to contain the HTTP/1.0\n, but that seems like a real hidden gotcha for anyone migrating from 2.6 to 3.0 - which is fine, as long as it's called out in the release notes. Yes, it is a bug in both squid and the balancer. Squid is supposed to be able to handle obsolete 0.9 anyway. We have to track it down and fix. But its not to say that the load balancer itself isn't 'broke' for sending 0.9 traffic. Amos
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
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
RE: [squid-users] parseHTTPRequest problem with SQUID3
On tis, 2008-11-11 at 15:24 +1300, Amos Jeffries wrote: 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. From this discussion it seems Squid-3 no longer accepts the obsolete HTTP/0.9 style requests. Squid-2 do support HTTP/0.9 in accelerator mode, including returning a HTTP/0.9 style response (no headers in either request or response). Regards Henrik signature.asc Description: This is a digitally signed message part
