Родитель
697970c1de
Коммит
881a8c4e10
|
@ -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
|
||||
|
|
Загрузка…
Ссылка в новой задаче