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
Received on 2015-10-08