cURL / Mailing Lists / curl-library / Single Mail


Re: curl_multi_info_read() returning result of CURLE_RECV_ERROR

From: KS Lee <>
Date: Wed, 4 Nov 2015 19:54:47 +0800

​Thank you, Ray, for the reply.​

> gmane.comp.web.curl.library by Ray Satiro via curl-library / 2h //
> keep unread // hide // preview
> That you have the same issue with WinSSL as you do OpenSSL leads me to
> believe this isn't a problem with either. You don't have this problem
> without SSL?

​The connection absolutely requires SSL, so it was a use-case we're stuck
with. We have used WinSSL, OpenSSL, LibreSSL - ended with the same i.e.
worked with a proxy in between, but failed with CURLE_RECV_ERROR without
the proxy.

> I apologize if this was answered already but I can only
> find part of the thread now. Is it possible that the reason you don't
> see an issue over a proxy like Fiddler is because you didn't use it
> enough to observe the issue there? In other words just because it
> appears to work fine through Fiddler a few times isn't the same as your
> normal use.

​We also convinced IT Security Audit to allow the proxy connection in the
interim using libcurl built with OpenSSL 1.0.2d. Has been running fine for
weeks already. Once the proxy is removed, bam, the error returns.

This is not a solution that our auditors like at all, and are pressing us
to remove the unauthorised proxy as soon as possible.

You wrote in another e-mail "Wireshark traces for the non-proxy
> scenario, it is showing a TCP disconnecting from libcurl, and then
> reconnecting at every HTTP interaction with the web server. This is
> normal behaviour, since keep-alive was not set." [1] Maybe the constant
> reconnection is why the issue can be more readily observed without a
> proxy.

​Yes, that was the hunch we went with.

> When you say keep alive are you referring to TCP keepalive or
> sending an actual Keep-Alive in the header which shouldn't be necessary
> with HTTP/1.1 since keepalive is the default?

We were wondering whether the proxy shielded the reconnections from the web
server.​ So, in some of our test cases, we enabled the libcurl KEEP-ALIVE
option and re-ran the test with the app that ran fine with a proxy. Again,
same problem.

​So, what's so special about putting a proxy service in between the
libcurl-calling app, and the HTTPS web server? That has stumped us.

At this point, we're willing to try anything.


List admin:
Received on 2015-11-04