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
Received on Fri Nov 05 2010 - 14:21:16 MDT
This archive was generated by hypermail 2.2.0 : Fri Nov 05 2010 - 12:00:02 MDT