Hi Michael, thank you for the reply. Here are the traces and settings we used for the proxy and non-proxy version.
> > *> * > *> We had a C++ code using libcurl running for the past five or so years, > was * > *> working fine until this week. * > *> * > *> This is a service that connects to a HTTPS-based IBM Websphere. It > sends & * > *> receives financial transactions. We don't operate the web server i.e. > it * > *> is third-party and hence, we have no control over it. * > *> * > *> Here's what stumping us: * > *> * > *> 1. The exact same program, if connected through a proxy server to the > same * > *> web server, runs without any errors. This service continues to run > with * > *> nary a blip. * > *> * > *> 2. The same code, running on a different server with NO proxy i.e. > directly * > *> connected to the web-server via a firewall, has decided to act up. * > *> Starting this past Monday, we've been consistenly getting the * > *> CURLE_RECV_ERROR "Failure when receiving data from the peer" after a * > *> successful POST. * > *> * > > 1. I assume HTTPS is used always with your service. > 2. There is no problem with establishing the SSL connection neither > directly > nor through the proxy. > > If 1 and 2 hold true, this should eliminate SSL as the problem, except > maybe > for some weird renegotiation stuff. > > I would look at the HTTP headers. See if theres anything that could cause > a > hickup on the remote end. Look at the response header you get from the web > server. Especially look at the differences in the headers when connecting > directly vs. via proxy. Post sanitized versions of those headers > here(remove > authentication data). This is the least that is needed to start guessing. > > Greeting, > Michael > For these tests, we upgraded libcurl to 7.44 using zlib & OpenSSL. The versions are as reported in the libcurl traces libcurl/7.44.0 OpenSSL/0.9.8k zlib/1.2.8 We re-ran the services to collect the detailed traces for a non-proxy and a proxy version again. Here are the settings and traces: 1. The Non-proxy version that failed with the CURLE_RECV_ERROR -- here are the traces captured, culminating with the closure of the connection by the peer. Trying XXXXXX... (** this is the external IP, through a gateway **) Name '192.168.128.61' family 2 resolved to '192.168.128.61' family 2 Local port: 0 Connected to * <http://ept.bursamalaysia.com>*** hostname *** (10.1.8.95) port 443 (#0) Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH SSL re-using session ID TLSv1.0 (OUT), TLS handshake, Client hello (1): TLSv1.0 (IN), TLS handshake, Server hello (2): TLSv1.0 (IN), TLS change cipher, Client hello (1): TLSv1.0 (IN), TLS handshake, Finished (20): TLSv1.0 (OUT), TLS change cipher, Client hello (1): TLSv1.0 (OUT), TLS handshake, Finished (20): SSL connection using TLSv1.0 / AES256-SHA Server certificate: subject: C=**; ST=**; L=**; O=**; CN=* <http://ept.bursamalaysia.com>* start date: 2014-10-27 00:00:00 GMT expire date: 2016-12-25 23:59:59 GMT issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 International Server CA - G3 SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway. POST **url string here** HTTP/1.1 Host: ******* User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 Accept: */* Accept-Encoding: deflate, gzip Referer: ******* Cookie: **** cookie string here **** Content-Length: 4476 Content-Type: application/x-www-form-urlencoded Expect: 100-continue Done waiting for 100-continue HTTP/1.1 200 OK content-encoding: gzip content-language: en-US content-type: text/html;charset=UTF-8 date: Thu, 08 Oct 2015 02:23:55 GMT p3p: CP="NON CUR OTPi OUR NOR UNI" server: WebSphere Application Server/8.0 transfer-encoding: chunked x-powered-by: Servlet/3.0 cache-control: no-cache,no-store,max-age=0 pragma: No-cache expires: Thu, 01 Jan 1970 00:00:00 GMT Replaced cookie PD-S-SESSION-ID="1_SwZIolTc6TxVzc6pbn0BGMG4BjM2Fy NviOTyNjHABFrHHTJLNZE=_AAAAAAE=_N/1yA0UjCQoq8e54hhWK92rPOqU=" for domain * <http://ept.bursamalaysia.com>***********, path /, expire 0 Set-Cookie: PD-S-SESSION-ID=1_SwZIolTc6TxVzc6pbn0BGMG4BjM2Fy NviOTyNjHABFrHHTJLNZE=_AAAAAAE=_N/1yA0UjCQoq8e54hhWK92rPOqU=; Path=/; Secure 180a <-- message length of the content **** then a series of debugging message type 3 in gzipped garbled text follows **** 6 such message type 3 fragments THEN ERROR HERE >>>> SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054 Closing connection 0 *** The service reported the CURLE_RECV_ERROR at curl_multi_info_read(). 2. The same program configured to run with a proxy did not encounter the error. We used a simple freeproxy service downloaded from the net. (We also did the same test with Fidder4 configured as a transparent proxy and it worked as well!) Trying 192.168.128.61... ****** this is the proxy's IP Name '192.168.128.61' family 2 resolved to '192.168.128.61' family 2 Local port: 0 Connected to 192.168.128.61 (192.168.128.61) port 8080 (#0) Establish HTTP proxy tunnel to ***hostname here***:443 CONNECT *** host name ***:443 HTTP/1.1 Host: *** host name ***:443 User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 Proxy-Connection: Keep-Alive HTTP/1.1 200 OK Server: FreeProxy/4.50 Date: Thu, 08 Oct 2015 02:50:04 GMT Content-Type: application/octet-stream Proxy replied OK to CONNECT request Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH SSL re-using session ID TLSv1.0 (OUT), TLS handshake, Client hello (1): TLSv1.0 (IN), TLS handshake, Server hello (2): TLSv1.0 (IN), TLS change cipher, Client hello (1): TLSv1.0 (IN), TLS handshake, Finished (20): TLSv1.0 (OUT), TLS change cipher, Client hello (1): TLSv1.0 (OUT), TLS handshake, Finished (20): SSL connection using TLSv1.0 / AES256-SHA Server certificate: subject: C=**; ST=**; L=**; O=**; CN=** start date: 2014-10-27 00:00:00 GMT expire date: 2016-12-25 23:59:59 GMT issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 International Server CA - G3 SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway. POST /was/webcds/account.do HTTP/1.1 Host:**** hostname **** User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 Accept: */* Accept-Encoding: deflate, gzip Referer: **** Cookie: **** cookie string here **** Content-Length: 4476 Content-Type: application/x-www-form-urlencoded Expect: 100-continue Done waiting for 100-continue HTTP/1.1 200 OK content-encoding: gzip content-language: en-US content-type: text/html;charset=UTF-8 date: Thu, 08 Oct 2015 02:50:07 GMT p3p: CP="NON CUR OTPi OUR NOR UNI" server: WebSphere Application Server/8.0 transfer-encoding: chunked x-powered-by: Servlet/3.0 cache-control: no-cache,no-store,max-age=0 pragma: No-cache expires: Thu, 01 Jan 1970 00:00:00 GMT Replaced cookie PD-S-SESSION-ID="1_DbDboI9tmpQZELxTAjZJbh5AGIT07PYVLR+2wj6vH0VBxmamnPg=_AAAAAAE=_sDHBuDvngeHwqKDmxPrzmXI1PNo=" for domain *****, path /, expire 0 Set-Cookie: PD-S-SESSION-ID=1_DbDboI9tmpQZELxTAjZJbh5AGIT07PYVLR+2wj6vH0VBxmamnPg=_AAAAAAE=_sDHBuDvngeHwqKDmxPrzmXI1PNo=; Path=/; Secure 180a <-- message length of the content **** then a series of debugging message type 3 in gzipped garbled text follows **** 6 such message type 3 fragments **** NOTE: the non-proxy version encountered the error here **** **** followed by another 6 message type 3 fragments as follows: Connection #0 to host 192.168.128.61 left intact *** Clean, no errors reported!! So, Michael, both the proxy and non-proxy versions had the similar messages and headers. The only problem was that the non-proxy version reported an error 10054 (connection reset by peer) after 6 messages were returned. The proxy version worked fine. We are stumped....help!
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
