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


Reply via email to