]> git.ipfire.org Git - thirdparty/curl.git/commitdiff
KNOWN_BUGS: Disconnects don't do verbose
authorDaniel Stenberg <daniel@haxx.se>
Sat, 14 Aug 2021 21:32:46 +0000 (23:32 +0200)
committerDaniel Stenberg <daniel@haxx.se>
Sat, 14 Aug 2021 21:32:46 +0000 (23:32 +0200)
Closes #6995

docs/KNOWN_BUGS

index 6116a572579fd1359e25f5a72eaeb6c38853f114..0a38623b3b713cef61c7f22099d5f7bb8808bd8e 100644 (file)
@@ -101,6 +101,7 @@ problems may have been fixed or changed somewhat since this was written!
  11. Internals
  11.1 Curl leaks .onion hostnames in DNS
  11.2 error buffer not set if connection to multiple addresses fails
+ 11.3 Disconnects don't do verbose
  11.4 HTTP test server 'connection-monitor' problems
  11.5 Connection information when using TCP Fast Open
  11.6 slow connect to localhost on Windows
@@ -772,6 +773,24 @@ problems may have been fixed or changed somewhat since this was written!
  CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER
  remains empty. Issue: https://github.com/curl/curl/issues/544
 
+11.3 Disconnects don't do verbose
+
+ Due to how libcurl keeps connections alive in the "connection pool" after use
+ to potentially trascend the life-time of the initial easy handle that was
+ used to drive the transfer over that connection, it uses a *separate* and
+ internal easy handle when it shutd down the connection. That separate
+ connection might not have the exact same settings as the original easy
+ handle, and in particular it is often note-worthy that it doesn't have the
+ same VERBOSE and debug callbcaks setup so that an application will not get
+ the protocol data for the disconnect phase of a transfer the same way it got
+ all the other data.
+
+ This is because the orginal easy handle might have already been freed at that
+ point and the applicaiton might not at all be prepared that the callback
+ would get called again long after the handle was freed.
+
+ See for example https://github.com/curl/curl/issues/6995
+
 11.4 HTTP test server 'connection-monitor' problems
 
  The 'connection-monitor' feature of the sws HTTP test server doesn't work