Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Strange very long time in curl_multi_cleanup() after an SSL request
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Frédéric BOITEUX via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 9 Nov 2023 17:04:02 +0000
Hello,
I'm using libcurl in a C program to perform various web operations. I'm using the 'multi' interface to be able to run multiple concurrent requests, in an asynchronous manner.
I'm working on Linux Debian systems, and I recently tried to migrate my program from a Debian 11 to Debian 12 version, with libcurl updated from 7.74 to 7.88 version. With this 'new' version, I've experienced an unexpected behaviour: sometimes, when closing my app [and libcurl], the call to curl_multi_cleanup() takes a [very] long time, more than 5 minutes !! After some tests, I could reproduce it doing an HTTPS request, then terminating.
I've search in Curl's changelog about an explanation, but as I didn't use this lib recently, and the changelog is quite huge between these 2 versions, I didn't find a clue about this problem at this point. I've tried the latest version (8.4.0) to see if it was a regression fixed meanwhile, without change. As all Curl versions aren't packaged in Debian, I finally has to compile and try each version to find in which one my problem arises : I found it in 7.78 version.
Then I've looked more carefully the 7.78 changelog, and suspected a commit, I tried to revert it and test the modified version, and my problem disappears :-)
This commit is :
Commit b249592d29ae0a2b3e8e07fdbc01f33b5a5b8420
Author: Michael Kaufmann <mail_at_michael-kaufmann.ch>
Date: Tue May 18 11:34:02 2021 +0200
ssl: read pending close notify alert before closing the connection
This avoids a TCP reset (RST) if the server initiates a connection
shutdown by sending an SSL close notify alert and then closes the TCP
connection.
For SSL connections, usually the server announces that it will close the
connection with an SSL close notify alert. curl should read this alert.
If curl does not read this alert and just closes the connection, some
operating systems close the TCP connection with an RST flag.
See RFC 1122, section 4.2.2.13
If curl reads the close notify alert, the TCP connection is closed
normally with a FIN flag.
The new code is similar to existing code in the "SSL shutdown" function:
try to read an alert (non-blocking), and ignore any read errors.
Closes #7095
I wonder if this strange behaviour is coming from my application ? I could try to build a test program, but it would take some time, and perhaps someone here could easily identify what is going wrong :-)
My app is single threaded, and I wrote it some years ago, following the very nice documentation "Everything Curl" ; I've checked if I miss some news/modifications in the API I should report in my app, but didn't find anything [it doesn't means I didn't miss something].
With regards,
Fred.
Date: Thu, 9 Nov 2023 17:04:02 +0000
Hello,
I'm using libcurl in a C program to perform various web operations. I'm using the 'multi' interface to be able to run multiple concurrent requests, in an asynchronous manner.
I'm working on Linux Debian systems, and I recently tried to migrate my program from a Debian 11 to Debian 12 version, with libcurl updated from 7.74 to 7.88 version. With this 'new' version, I've experienced an unexpected behaviour: sometimes, when closing my app [and libcurl], the call to curl_multi_cleanup() takes a [very] long time, more than 5 minutes !! After some tests, I could reproduce it doing an HTTPS request, then terminating.
I've search in Curl's changelog about an explanation, but as I didn't use this lib recently, and the changelog is quite huge between these 2 versions, I didn't find a clue about this problem at this point. I've tried the latest version (8.4.0) to see if it was a regression fixed meanwhile, without change. As all Curl versions aren't packaged in Debian, I finally has to compile and try each version to find in which one my problem arises : I found it in 7.78 version.
Then I've looked more carefully the 7.78 changelog, and suspected a commit, I tried to revert it and test the modified version, and my problem disappears :-)
This commit is :
Commit b249592d29ae0a2b3e8e07fdbc01f33b5a5b8420
Author: Michael Kaufmann <mail_at_michael-kaufmann.ch>
Date: Tue May 18 11:34:02 2021 +0200
ssl: read pending close notify alert before closing the connection
This avoids a TCP reset (RST) if the server initiates a connection
shutdown by sending an SSL close notify alert and then closes the TCP
connection.
For SSL connections, usually the server announces that it will close the
connection with an SSL close notify alert. curl should read this alert.
If curl does not read this alert and just closes the connection, some
operating systems close the TCP connection with an RST flag.
See RFC 1122, section 4.2.2.13
If curl reads the close notify alert, the TCP connection is closed
normally with a FIN flag.
The new code is similar to existing code in the "SSL shutdown" function:
try to read an alert (non-blocking), and ignore any read errors.
Closes #7095
I wonder if this strange behaviour is coming from my application ? I could try to build a test program, but it would take some time, and perhaps someone here could easily identify what is going wrong :-)
My app is single threaded, and I wrote it some years ago, following the very nice documentation "Everything Curl" ; I've checked if I miss some news/modifications in the API I should report in my app, but didn't find anything [it doesn't means I didn't miss something].
With regards,
Fred.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-11-09