Re: [squid-users] client_side_request.cc messages in cache.log
On Nov 5, 2010, at 7:37 PM, Amos Jeffries wrote: On 06/11/10 03:28, donovan jeffrey j wrote: On Nov 5, 2010, at 10:24 AM, Amos Jeffries wrote: On 06/11/10 03:20, donovan jeffrey j wrote: snip does this look right ? #redirect_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf #redirect_children 100 url_rewrite_children 100 Yes. is it okay to issue a - k reconfigure for this change or it better to wait until not many users are accessing? -j reconfigure is enough. It is just a cosmetic config change at this point. Amos okay im getting same message under load. 2010/11/08 09:04:50| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x2135be20*2 from request 0x14e14200 to 0x8ac0200 2010/11/08 09:04:56| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x1fabb330*2 from request 0xc7a5e00 to 0xe05d000 2010/11/08 09:05:00| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x2135be20*1 from request 0x8fa7200 to 0x127f7400 2010/11/08 09:05:06| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x20606560*1 from request 0x11508200 to 0x11add800 2010/11/08 09:05:07| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x21278360*1 from request 0xbcbc00 to 0x190d4a00 and yes there is redirection going on so it's not lying to me. ^^^ client redirect done. is this just a notification of the redirect ? or is it an error ? -j
Re: [squid-users] client_side_request.cc messages in cache.log
On 09/11/10 03:08, donovan jeffrey j wrote: On Nov 5, 2010, at 7:37 PM, Amos Jeffries wrote: On 06/11/10 03:28, donovan jeffrey j wrote: On Nov 5, 2010, at 10:24 AM, Amos Jeffries wrote: On 06/11/10 03:20, donovan jeffrey j wrote: snip does this look right ? #redirect_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf #redirect_children 100 url_rewrite_children 100 Yes. is it okay to issue a - k reconfigure for this change or it better to wait until not many users are accessing? -j reconfigure is enough. It is just a cosmetic config change at this point. Amos okay im getting same message under load. 2010/11/08 09:04:50| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x2135be20*2 from request 0x14e14200 to 0x8ac0200 2010/11/08 09:04:56| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x1fabb330*2 from request 0xc7a5e00 to 0xe05d000 2010/11/08 09:05:00| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x2135be20*1 from request 0x8fa7200 to 0x127f7400 2010/11/08 09:05:06| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x20606560*1 from request 0x11508200 to 0x11add800 2010/11/08 09:05:07| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x21278360*1 from request 0xbcbc00 to 0x190d4a00 and yes there is redirection going on so it's not lying to me. ^^^ client redirect done. is this just a notification of the redirect ? or is it an error ? It's a notice that the redirect changed something potentially dodgy. I've canvased the dev who might know better than me and have not come up with any reason to keep it. It may be worth adding url_rewrite_access deny CONNECT if possible to protect against tunnel problems. Beyond that it can be ignored or patched out of existence. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.9 Beta testers wanted for 3.2.0.2
Re: [squid-users] client_side_request.cc messages in cache.log
On Nov 4, 2010, at 11:10 PM, Amos Jeffries wrote: On 05/11/10 05:23, donovan jeffrey j wrote: I On Nov 4, 2010, at 12:09 PM, Dean Weimer wrote: I just setup a new site through my reverse proxy running Squid 3.1.9, and though it's working fine, I am receiving the follow message every time an url on the new site is accessed. 010/11/04 10:39:32| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x8016a1e38*1 from request 0x802637800 to 0x802242000 The url in question is an HTTPS url, and is passed through a self written url rewrite program (written in Python), I have verified that the processes are not crashing or causing any internal errors when rewriting this url. The application is a vendor provided ASP.net application running on IIS 6.0. So far it's only available to internal users, for testing so there isn't a heavy load for this url on the proxy yet. There isn't any perceivable difference in performance between the reverse proxy and accessing the site directly (Though I wouldn't expect to see the performance advantages of Squid with the currently load on the backend server being next to nothing at this point), so whatever is causing the error doesn't seem to be affecting performance. I am concerned that this message may be a sign of a more major problem when the server gets placed under a larger load. Thanks, Dean Weimer I am seeing the same things ,I think it's normal behavior but im not sure either. 2010/11/04 12:19:12| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0xcc167c0*2 from request 0x96c400 to 0xa326a00 2010/11/04 12:19:15| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x140dbb70*1 from request 0x3dc5c00 to 0x2cd6c00 2010/11/04 12:19:43| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x1b8b350*1 from request 0xa3b4000 to 0x314 -j At first glance it seems to be a debug message which has been left at the wrong priority. It indicates that the connection was URL re-written instead of HTTP redirected. squid -d1 It should be noted that re-writing the HTTPS / CONNECT request URL is a very dangerous activity. It will result directly in the client connecting and sending SSL credentials to a server it was not intending to contact at all. The safe way to do it is with a true HTTP redirect via the 302:/303:/307: status code. Unfortunately some browsers dont like these, so transition to correct usage needs to be done with care. Amos not sure I intended to re-write anything on purpose. squid 3.1.9 running transparent with SquidGuard. https is not proxied it goes direct # - acl manager proto cache_object acl localhost src 127.0.0.1/32 acl localnet src x.x.x.x # #windows updates # acl windowsupdate dstdomain windowsupdate.microsoft.com acl windowsupdate dstdomain .update.microsoft.com acl windowsupdate dstdomain download.windowsupdate.com acl windowsupdate dstdomain redir.metaservices.microsoft.com acl windowsupdate dstdomain images.metaservices.microsoft.com acl windowsupdate dstdomain c.microsoft.com acl windowsupdate dstdomain www.download.windowsupdate.com acl windowsupdate dstdomain wustat.windows.com acl windowsupdate dstdomain crl.microsoft.com acl CONNECT method CONNECT acl wuCONNECT dstdomain www.update.microsoft.com http_access allow CONNECT wuCONNECT localnet http_access allow CONNECT wuCONNECT localhost http_access allow windowsupdate localnet http_access allow windowsupdate localhost # http_access allow manager localhost http_access allow localnet # And finally deny all other access to this proxy http_access deny all # NETWORK OPTIONS # - #http_port 3128 http_port 10.0.x.x:3128 transparent # REDIRECT OPTIONS # - redirect_program/usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf redirect_children 100 cache_mem 256 MB maximum_object_size_in_memory 512 KB ipcache_size 1024 cache_dir ufs /Volumes/cache2/cache 65535 16 256 cache_dir ufs /Volumes/cache3/cache 65535 16 256 maximum_object_size 4096 KB access_log /usr/local/squid/var/logs/access.log cache_log /usr/local/squid/var/logs/cache.log cache_store_log none #Suggested default: refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern (cgi-bin|\?)0 0% 0 refresh_pattern . 0 20% 4320 range_offset_limit -1 cache_effective_user squid cache_effective_group wheel visible_hostname hook2 shutdown_lifetime 10 seconds
Re: [squid-users] client_side_request.cc messages in cache.log
On 06/11/10 01:55, donovan jeffrey j wrote: On Nov 4, 2010, at 11:10 PM, Amos Jeffries wrote: On 05/11/10 05:23, donovan jeffrey j wrote: I On Nov 4, 2010, at 12:09 PM, Dean Weimer wrote: I just setup a new site through my reverse proxy running Squid 3.1.9, and though it's working fine, I am receiving the follow message every time an url on the new site is accessed. 010/11/04 10:39:32| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x8016a1e38*1 from request 0x802637800 to 0x802242000 The url in question is an HTTPS url, and is passed through a self written url rewrite program (written in Python), I have verified that the processes are not crashing or causing any internal errors when rewriting this url. The application is a vendor provided ASP.net application running on IIS 6.0. So far it's only available to internal users, for testing so there isn't a heavy load for this url on the proxy yet. There isn't any perceivable difference in performance between the reverse proxy and accessing the site directly (Though I wouldn't expect to see the performance advantages of Squid with the currently load on the backend server being next to nothing at this point), so whatever is causing the error doesn't seem to be affecting performance. I am concerned that this message may be a sign of a more major problem when the server gets placed under a larger load. Thanks, Dean Weimer I am seeing the same things ,I think it's normal behavior but im not sure either. 2010/11/04 12:19:12| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0xcc167c0*2 from request 0x96c400 to 0xa326a00 2010/11/04 12:19:15| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x140dbb70*1 from request 0x3dc5c00 to 0x2cd6c00 2010/11/04 12:19:43| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x1b8b350*1 from request 0xa3b4000 to 0x314 -j At first glance it seems to be a debug message which has been left at the wrong priority. It indicates that the connection was URL re-written instead of HTTP redirected. squid -d1 It should be noted that re-writing the HTTPS / CONNECT request URL is a very dangerous activity. It will result directly in the client connecting and sending SSL credentials to a server it was not intending to contact at all. The safe way to do it is with a true HTTP redirect via the 302:/303:/307: status code. Unfortunately some browsers dont like these, so transition to correct usage needs to be done with care. Amos not sure I intended to re-write anything on purpose. squid 3.1.9 running transparent with SquidGuard. https is not proxied it goes direct squidguard is a re-writer. The message is caused by its output back to Squid. I would hope it is only configured on purpose ;-) snip # NETWORK OPTIONS # - #http_port 3128 http_port 10.0.x.x:3128 transparent # REDIRECT OPTIONS # - redirect_program/usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf redirect_children 100 These directives are deprecated Rename them to url_rewrite_program and url_rewrite_children there will be no operational difference in 3.1.9 but will save upgrade problems later. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.9 Beta testers wanted for 3.2.0.2
Re: [squid-users] client_side_request.cc messages in cache.log
On Nov 5, 2010, at 9:27 AM, Amos Jeffries wrote: On 06/11/10 01:55, donovan jeffrey j wrote: On Nov 4, 2010, at 11:10 PM, Amos Jeffries wrote: On 05/11/10 05:23, donovan jeffrey j wrote: I On Nov 4, 2010, at 12:09 PM, Dean Weimer wrote: I just setup a new site through my reverse proxy running Squid 3.1.9, and though it's working fine, I am receiving the follow message every time an url on the new site is accessed. 010/11/04 10:39:32| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x8016a1e38*1 from request 0x802637800 to 0x802242000 The url in question is an HTTPS url, and is passed through a self written url rewrite program (written in Python), I have verified that the processes are not crashing or causing any internal errors when rewriting this url. The application is a vendor provided ASP.net application running on IIS 6.0. So far it's only available to internal users, for testing so there isn't a heavy load for this url on the proxy yet. There isn't any perceivable difference in performance between the reverse proxy and accessing the site directly (Though I wouldn't expect to see the performance advantages of Squid with the currently load on the backend server being next to nothing at this point), so whatever is causing the error doesn't seem to be affecting performance. I am concerned that this message may be a sign of a more major problem when the server gets placed under a larger load. Thanks, Dean Weimer I am seeing the same things ,I think it's normal behavior but im not sure either. 2010/11/04 12:19:12| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0xcc167c0*2 from request 0x96c400 to 0xa326a00 2010/11/04 12:19:15| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x140dbb70*1 from request 0x3dc5c00 to 0x2cd6c00 2010/11/04 12:19:43| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x1b8b350*1 from request 0xa3b4000 to 0x314 -j At first glance it seems to be a debug message which has been left at the wrong priority. It indicates that the connection was URL re-written instead of HTTP redirected. squid -d1 It should be noted that re-writing the HTTPS / CONNECT request URL is a very dangerous activity. It will result directly in the client connecting and sending SSL credentials to a server it was not intending to contact at all. The safe way to do it is with a true HTTP redirect via the 302:/303:/307: status code. Unfortunately some browsers dont like these, so transition to correct usage needs to be done with care. Amos not sure I intended to re-write anything on purpose. squid 3.1.9 running transparent with SquidGuard. https is not proxied it goes direct squidguard is a re-writer. The message is caused by its output back to Squid. I would hope it is only configured on purpose ;-) snip # NETWORK OPTIONS # - #http_port 3128 http_port 10.0.x.x:3128 transparent # REDIRECT OPTIONS # - redirect_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf redirect_children 100 These directives are deprecated Rename them to url_rewrite_program and url_rewrite_children there will be no operational difference in 3.1.9 but will save upgrade problems later. does this look right ? #redirect_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf #redirect_children 100 url_rewrite_children 100 -j
Re: [squid-users] client_side_request.cc messages in cache.log
On 06/11/10 03:20, donovan jeffrey j wrote: snip does this look right ? #redirect_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf #redirect_children 100 url_rewrite_children 100 Yes. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.9 Beta testers wanted for 3.2.0.2
Re: [squid-users] client_side_request.cc messages in cache.log
On Nov 5, 2010, at 10:24 AM, Amos Jeffries wrote: On 06/11/10 03:20, donovan jeffrey j wrote: snip does this look right ? #redirect_program/usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf #redirect_children 100 url_rewrite_children 100 Yes. is it okay to issue a - k reconfigure for this change or it better to wait until not many users are accessing? -j
Re: [squid-users] client_side_request.cc messages in cache.log
On 06/11/10 03:28, donovan jeffrey j wrote: On Nov 5, 2010, at 10:24 AM, Amos Jeffries wrote: On 06/11/10 03:20, donovan jeffrey j wrote: snip does this look right ? #redirect_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf #redirect_children 100 url_rewrite_children 100 Yes. is it okay to issue a - k reconfigure for this change or it better to wait until not many users are accessing? -j reconfigure is enough. It is just a cosmetic config change at this point. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.9 Beta testers wanted for 3.2.0.2
[squid-users] client_side_request.cc messages in cache.log
I just setup a new site through my reverse proxy running Squid 3.1.9, and though it's working fine, I am receiving the follow message every time an url on the new site is accessed. 010/11/04 10:39:32| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x8016a1e38*1 from request 0x802637800 to 0x802242000 The url in question is an HTTPS url, and is passed through a self written url rewrite program (written in Python), I have verified that the processes are not crashing or causing any internal errors when rewriting this url. The application is a vendor provided ASP.net application running on IIS 6.0. So far it's only available to internal users, for testing so there isn't a heavy load for this url on the proxy yet. There isn't any perceivable difference in performance between the reverse proxy and accessing the site directly (Though I wouldn't expect to see the performance advantages of Squid with the currently load on the backend server being next to nothing at this point), so whatever is causing the error doesn't seem to be affecting performance. I am concerned that this message may be a sign of a more major problem when the server gets placed under a larger load. Thanks, Dean Weimer Network Administrator Orscheln Management Co
Re: [squid-users] client_side_request.cc messages in cache.log
I On Nov 4, 2010, at 12:09 PM, Dean Weimer wrote: I just setup a new site through my reverse proxy running Squid 3.1.9, and though it's working fine, I am receiving the follow message every time an url on the new site is accessed. 010/11/04 10:39:32| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x8016a1e38*1 from request 0x802637800 to 0x802242000 The url in question is an HTTPS url, and is passed through a self written url rewrite program (written in Python), I have verified that the processes are not crashing or causing any internal errors when rewriting this url. The application is a vendor provided ASP.net application running on IIS 6.0. So far it's only available to internal users, for testing so there isn't a heavy load for this url on the proxy yet. There isn't any perceivable difference in performance between the reverse proxy and accessing the site directly (Though I wouldn't expect to see the performance advantages of Squid with the currently load on the backend server being next to nothing at this point), so whatever is causing the error doesn't seem to be affecting performance. I am concerned that this message may be a sign of a more major problem when the server gets placed under a larger load. Thanks, Dean Weimer I am seeing the same things ,I think it's normal behavior but im not sure either. 2010/11/04 12:19:12| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0xcc167c0*2 from request 0x96c400 to 0xa326a00 2010/11/04 12:19:15| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x140dbb70*1 from request 0x3dc5c00 to 0x2cd6c00 2010/11/04 12:19:43| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x1b8b350*1 from request 0xa3b4000 to 0x314 -j
Re: [squid-users] client_side_request.cc messages in cache.log
On 05/11/10 05:23, donovan jeffrey j wrote: I On Nov 4, 2010, at 12:09 PM, Dean Weimer wrote: I just setup a new site through my reverse proxy running Squid 3.1.9, and though it's working fine, I am receiving the follow message every time an url on the new site is accessed. 010/11/04 10:39:32| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x8016a1e38*1 from request 0x802637800 to 0x802242000 The url in question is an HTTPS url, and is passed through a self written url rewrite program (written in Python), I have verified that the processes are not crashing or causing any internal errors when rewriting this url. The application is a vendor provided ASP.net application running on IIS 6.0. So far it's only available to internal users, for testing so there isn't a heavy load for this url on the proxy yet. There isn't any perceivable difference in performance between the reverse proxy and accessing the site directly (Though I wouldn't expect to see the performance advantages of Squid with the currently load on the backend server being next to nothing at this point), so whatever is causing the error doesn't seem to be affecting performance. I am concerned that this message may be a sign of a more major problem when the server gets placed under a larger load. Thanks, Dean Weimer I am seeing the same things ,I think it's normal behavior but im not sure either. 2010/11/04 12:19:12| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0xcc167c0*2 from request 0x96c400 to 0xa326a00 2010/11/04 12:19:15| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x140dbb70*1 from request 0x3dc5c00 to 0x2cd6c00 2010/11/04 12:19:43| client_side_request.cc(1047) clientRedirectDone: redirecting body_pipe 0x1b8b350*1 from request 0xa3b4000 to 0x314 -j At first glance it seems to be a debug message which has been left at the wrong priority. It indicates that the connection was URL re-written instead of HTTP redirected. It should be noted that re-writing the HTTPS / CONNECT request URL is a very dangerous activity. It will result directly in the client connecting and sending SSL credentials to a server it was not intending to contact at all. The safe way to do it is with a true HTTP redirect via the 302:/303:/307: status code. Unfortunately some browsers dont like these, so transition to correct usage needs to be done with care. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.9 Beta testers wanted for 3.2.0.2