Hi
This problem has stumped us for a good part of this past week.

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.

3. We enabled all tracing from libcurl CURLOPT_DEBUGFUNCTION. We do see
fragments of messages coming back and are duly collected into a buffer
properly.

4. We know something on the third-party web server has changed, but we
don't know what, and the operator of the site is under no obligation to
tell us anything. And they don't.

5. What we have tried so far, with no success:
a. Changing the User-Agent string to use more "modern" browser
identification.

b. The code fragment (assumed variables defined, this is a large routine):

            CURLcode curlCode = CURLE_READ_ERROR; // Dummy value
            while ( ( pCurlMsg = curl_multi_info_read( m_pMultiCurlHandle,
&msgs_left ) ) )
            {
                if ( pCurlMsg->msg == CURLMSG_DONE )
                {
                    curlCode = pCurlMsg->data.result;
                    curl_easy_getinfo( pCurlMsg->easy_handle,

 CURLINFO_RESPONSE_CODE,
                                                         &lHttpResponseCode
);
                    break; // Out of while loop
                }
            }

         // At this point:
         // curlCode == CURLE_RECV_ERROR if we are not connecting via a
proxy!!

6. Here are the libcurl settings called for the non-proxy version:

curl_global_init(CURL_GLOBAL_ALL);
curl_easy_setopt(m_pCurl, CURLOPT_USERAGENT, "bla bla bla");
curl_easy_setopt(m_pCurl, CURLOPT_WRITEFUNCTION, HttpGetCallback);
curl_easy_setopt(m_pCurl, CURLOPT_WRITEDATA, &m_stHTMLPage);
curl_easy_setopt(m_pCurl, CURLOPT_DEBUGFUNCTION, CurlDebugCallback);
curl_easy_setopt(m_pCurl, CURLOPT_DEBUGDATA, this);
curl_easy_setopt(m_pCurl, CURLOPT_VERBOSE, true);
curl_easy_setopt(m_pCurl, CURLOPT_AUTOREFERER, 1);
curl_easy_setopt(m_pCurl, CURLOPT_UNRESTRICTED_AUTH, 1);
curl_easy_setopt(m_pCurl, CURLOPT_HEADER, 1);
curl_easy_setopt(m_pCurl, CURLOPT_SSL_VERIFYPEER, 0);
curl_easy_setopt(m_pCurl, CURLOPT_SSL_VERIFYHOST, 0);
curl_easy_setopt(m_pCurl, CURLOPT_COOKIEFILE, "");
curl_easy_setopt(m_pCurl, CURLOPT_COOKIESESSION , 1);
curl_easy_setopt(m_pCurl, CURLOPT_FOLLOWLOCATION, 1);
curl_easy_setopt(m_pCurl, CURLOPT_ACCEPT_ENCODING, "deflate, gzip");
curl_easy_setopt(m_pCurl, CURLOPT_INTERFACE, "192.168.128.61"); // some IP

 7. What can possibly be changed on the third-party that could have
affected this non-proxy service but NOT the one connected through a proxy.
They are the exact SAME program!

Any help is deeply appreciated.

Kind regards
KS

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-10-07