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 0x3140000
>>
>> -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: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 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
Received on Fri Nov 05 2010 - 12:56:09 MDT
This archive was generated by hypermail 2.2.0 : Fri Nov 05 2010 - 12:00:01 MDT