cURL / Mailing Lists / curl-library / Single Mail


Re: about https proxy queston

From: laser peter via curl-library <>
Date: Fri, 30 Jan 2015 09:33:15 +0000 (UTC)

Any update? Would you please take a look?

     On Tuesday, January 27, 2015 6:03 PM, laser peter via curl-library <> wrote:

  Hi, our client app will failed to connect to the server through https_proxy when I use libcurl 7.39 in our client app, the libcurl 7.32 doesnt' have the issue, could you please take look into it? Look like the root cause is that the timer of curl could time out over the certain proxy and subsequently CURL_SOCKET_TIMEOUT would be sent to curl so that the underlying socket would be closed by curl resulting in the connection being failed, which works fine using curl 7.32.I spotted the below code of file “multi.c” in curl 7.32 was removed but with “memset(&multi->timer_lastcall, 0, sizeof(multi->timer_lastcall));” instead in curl 7.39, which might be the partial reason. Could you help look into it?  /* Compensate for bad precision timers that might've triggered too early.     This precaution was added in commit 2c72732ebf3da5e as a result of bad
     resolution in the windows function use(d).
     The problematic case here is when using the multi_socket API and libcurl
     has told the application about a timeout, and that timeout is what fires
     off a bit early. As we don't have any IDs associated with the timeout we
     can't tell which timeout that fired off but we only have the times to use
     to check what to do. If it fires off too early, we don't run the correct
     actions and we don't tell the application again about the same timeout as
     was already first in the queue...
     Originally we made the timeouts run 40 milliseconds early on all systems,
     but now we have an #ifdef setup to provide a decent precaution inaccuracy
     margin.  */  now.tv_usec += TIMEOUT_INACCURACY;  if(now.tv_usec >= 1000000) {    now.tv_sec++;
    now.tv_usec -= 1000000;
  }2 potential workarounds on app side rather than libcurl are:
(1)     If timeout happens, never send CURL_SOCKET_TIMEOUT to curl;(2)     Don’t register CURLMOPT_TIMERFUNCTION callback; Or Never register curl timers.
As normally our Client only has one connection at one time, could you please check the feasibility of these workarounds?

List admin:


List admin:
Received on 2015-01-30