Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 71389 invoked from network); 9 Feb 2009 22:57:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2009 22:57:08 -0000 Received: (qmail 24416 invoked by uid 500); 9 Feb 2009 22:56:57 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 23952 invoked by uid 500); 9 Feb 2009 22:56:56 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 23943 invoked by uid 99); 9 Feb 2009 22:56:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 14:56:56 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of prvs=284e23a79=Eric.Webb@cooperindustries.com designates 216.130.131.68 as permitted sender) Received: from [216.130.131.68] (HELO cooperlighting-sw.cooperlighting.com) (216.130.131.68) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 22:56:48 +0000 Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.37,407,1231131600"; d="scan'208,217";a="251879148" Received: from cipt0174.cooperlighting.com (HELO cipt0174.NAM.CI.ROOT) ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 09 Feb 2009 17:57:36 -0500 Received: from EVS1.NAM.CI.ROOT ([10.132.108.169]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 17:56:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98B09.A1177E4B" Date: Mon, 9 Feb 2009 17:56:24 -0500 Message-ID: <19FA255C3FD05340A1AF33119C9A2225013F71B6@EVS1.NAM.CI.ROOT> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProxyPass and connection reset by peer Thread-Index: AcmLCaG+4K+86f2cSaKS7/prcC32Jg== From: "Webb, Eric" To: X-OriginalArrivalTime: 09 Feb 2009 22:56:23.0583 (UTC) FILETIME=[A16A3AF0:01C98B09] X-Virus-Checked: Checked by ClamAV on apache.org Subject: [users@httpd] ProxyPass and connection reset by peer ------_=_NextPart_001_01C98B09.A1177E4B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Hi all, =20 I am running httpd 1.3.37 on Linux 2.4.33.3 as a reverse proxy server fronting a corporate web portal to the Internet. Lately, I have seen a rise in client complaints of web pages not loading completely, and when I check Apache logs I see several messages like the following directly tied to what the particular user was doing: =20 [Fri Feb 6 16:41:17 2009] [error] [client 11.222.333.444] (104)Connection reset by peer: proxy: error r eading from https://www.someplace.com/irj/servlet/prt/portal/prtpos/com!252esap!252e portal!252enavigation !252eportallauncher!252edefault!7b!3b1!7d/prttarget/pcd!253aportal_conte nt!252fcom!252ecooper!252efl_coo per_internal!252fcom!252ecooper!252efl_cooper_internal_iviews!252fcom!25 2ecooper!252eCooperCustomerCente r!252fcom!252ecooper!252eDesktop!252fcom!252ecooper!252eNewCCCDefaultDes ktop!252fframeworkPages!252fcom! 252ecooper!252eportal!252eNew_CCC_Light_Framework_Page.com!252esap!252ep ortal!252elightinnerpage.com!252 ecooper!252eCCCContentAreaLight.content/prteventname/HtmlbEvent/prtroot/ com.sap.portal.navigation.portal launcher.default =20 The connection path is Browser -> [SSL] -> ReverseProxy -> [ProxyPass] -> [SSL] -> AppServer=20 =20 When the reverse proxy is bypassed (ie, accessed from internal network) we don't see this issue at all. Feedback I'm getting from the apps people after comparing TCPDUMP traces is that the reverse proxy box is resetting connections instead of going through the normal FIN/ACK handshake process. Although, from the above error log entry, it appears that it is the app server which is resetting the connection. =20 My questions so far: =20 1) What is the above error really telling me? =20 2) Am I correct that the connection which was reset was RP -> appserver, and not browser -> RP? 3) Who is really resetting the connection, the RP or the app server? 4) This issue has been seen off and on for the past year, but has become worse in the past two months. I theorize the problem to be increased traffic / volume-related, as this reverse proxy also services a few other domains. Is there any information available on kernel (IP stack) or HTTP parameter tuning for such a server? 5) I see SSL config directives that allow me to limit which SSL protocol I will allow from the client. Is there any way to force the SSL protocol (and even the encryption method) that I use when ProxyPass opens the socket to my app server? =20 =20 Thanks! =20 =20 =20 Eric C. Webb Sr. Systems Analyst / Unix System Administrator Cooper Industries IT Solutions & Services (770) 486-4623 FAX: (770) 486-4677 =20 ------_=_NextPart_001_01C98B09.A1177E4B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

Hi all,

 

I am running httpd 1.3.37 on Linux 2.4.33.3 as a = reverse proxy server fronting a corporate web portal to the Internet.  = Lately, I have seen a rise in client complaints of web pages not loading completely, = and when I check Apache logs I see several messages like the following directly = tied to what the particular user was doing:

 

[Fri Feb  6 16:41:17 2009] [error] [client = 11.222.333.444] (104)Connection reset by peer: proxy: error = r

eading from = https://www.someplace.com/irj/servlet/prt/portal/prtpos/com!252esap!252ep= ortal!252enavigation

!252eportallauncher!252edefault!7b!3b1!7d/prttarget/pc= d!253aportal_content!252fcom!252ecooper!252efl_coo

per_internal!252fcom!252ecooper!252efl_cooper_internal= _iviews!252fcom!252ecooper!252eCooperCustomerCente

r!252fcom!252ecooper!252eDesktop!252fcom!252ecooper!25= 2eNewCCCDefaultDesktop!252fframeworkPages!252fcom!

252ecooper!252eportal!252eNew_CCC_Light_Framework_Page= .com!252esap!252eportal!252elightinnerpage.com!252

ecooper!252eCCCContentAreaLight.content/prteventname/H= tmlbEvent/prtroot/com.sap.portal.navigation.portal

launcher.default

 

The connection path is    Browser = -> [SSL] -> ReverseProxy -> [ProxyPass] -> [SSL] -> AppServer =

 

When the reverse proxy is bypassed (ie, accessed from internal network) we don’t see this issue at all.  Feedback = I’m getting from the apps people after comparing TCPDUMP traces is that the = reverse proxy box is resetting connections instead of going through the normal = FIN/ACK handshake process.  Although, from the above error log entry, it = appears that it is the app server which is resetting the = connection.

 

My questions so far:

 

1)       = What is the above error really telling me? 

2)       = Am I correct that the connection which was reset was RP -> appserver, and not = browser -> RP?

3)       = Who is really resetting the connection, the RP or the app = server?

4)       = This issue has been seen off and on for the past year, but has become worse in the = past two months.  I theorize the problem to be increased traffic / = volume-related, as this reverse proxy also services a few other domains.  Is there = any information available on kernel (IP stack) or HTTP parameter tuning for = such a server?

5)       = I see SSL config directives that allow me to limit which SSL protocol I will allow = from the client.  Is there any way to force the SSL protocol (and even = the encryption method) that I use when ProxyPass opens the socket to my app = server?

 

 

Thanks!

 

 

 

Eric C. Webb
Sr. Systems = Analyst / Unix System = Administrator


Cooper Industries IT = Solutions & Services
(770) 486-4623   FAX: (770) 486-4677

 

------_=_NextPart_001_01C98B09.A1177E4B--