#1327 libcurl prunes CURLOPT_RESOLVE entries after detecting a dead connection

closed-fixed
None
5
2015-02-15
2014-01-27
No

[#1303] reports an issue (now fixed) where libcurl would prune CURLOPT_RESOLVE entries after the DNS cache timeout had elapsed.

It looks like the patch is not complete, though. As of version 7.34.1-dev entries are still being incorrectly removed in the following scenario:

  • client starts the connection and server keeps it alive
  • CURLOPT_DNS_CACHE_TIMEOUT elapses
  • server kills the connection
  • client starts a new request, finds the connection to be dead and creates a new one

The attached program is basically the same one attached to bug report [#1303], except it connects to a server which keeps the connection alive for a short time (debian.org), instead of the other one, which always signaled the client to close it.

Here's the output:

Test started with libcurl/7.34.1-DEV OpenSSL/1.0.1e zlib/1.2.8 libidn/1.28 librtmp/2.3
debug: Added fake.host:80:150.203.164.38 to DNS cache
debug: Rebuilt URL to: http://fake.host/
debug: Hostname was found in DNS cache
debug:   Trying 150.203.164.38...
debug: Connected to fake.host (150.203.164.38) port 80 (#0)
debug: Server Apache is not blacklisted
debug: Connection #0 to host fake.host left intact
HTTP transfer completed with status 0
Sleeping for 20 seconds...
debug: Added fake.host:80:150.203.164.38 to DNS cache
debug: Rebuilt URL to: http://fake.host/
debug: Found bundle for host fake.host: 0xcacc20
debug: Connection 0 seems to be dead!
debug: Closing connection 0
debug: Hostname was NOT found in DNS cache
debug: getaddrinfo(3) failed for fake.host:80
debug: Couldn't resolve host 'fake.host'
debug: Closing connection 1
HTTP transfer completed with status 6
1 Attachments

Related

Bugs: #1303

Discussion

  • Daniel Stenberg

    Daniel Stenberg - 2014-01-28
    • assigned_to: Daniel Stenberg
     
  • Daniel Stenberg

    Daniel Stenberg - 2014-01-28

    Lovely, thanks. Have you tried writing up a test case that repeats the problem and verifies the fix?

     
  • Romulo A. Ceccon

    Daniel, I remember I invested a short time trying to write one when I reported [#1303] and couldn't figure out how to do it. I'll give it another try as soon as I find free time.

     

    Related

    Bugs: #1303

  • Romulo A. Ceccon

    What do you think is more appropriate here, a "unit" test or a "libtest"?

     
  • Daniel Stenberg

    Daniel Stenberg - 2014-01-28

    I would think that a full libtest is easier to mimic the exact case you explained in this bug report, even though I guess single functions could benefit from unit tests as well!

     
  • Daniel Stenberg

    Daniel Stenberg - 2014-01-28

    Thanks, your patch has been merged and pushed. I would still be very glad to see a test for this and I can also help with that. Would you like this issue to be held open as a reminder of that or not?

     
  • Daniel Stenberg

    Daniel Stenberg - 2014-01-28
    • status: open --> open-confirmed
     
  • Romulo A. Ceccon

    Keep it open. Thanks.

     
  • Daniel Stenberg

    Daniel Stenberg - 2014-02-20
    • status: open-confirmed --> closed-fixed
     
  • Daniel Stenberg

    Daniel Stenberg - 2014-02-20

    Thanks, merged and this case is closed!

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks