-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Description
I did this
My software depends on libcurl for HTTP transfers. It uses the easy interface, and re-uses the handles for multiple transfers. In order to avoid leaking options (e.g. headers), the handle is reset after each transfer.
Commit fd6eb8d broke my test suite because cookies were no longer sent. The problem is that they aren't written to the cookie jar. Apparently what happens is:
- I create a curl handle
- I set all the options I need for the current transfer
- I do the transfer with
curl_easy_perform() - I reset the options with
curl_easy_reset(), then set theCURLOPT_COOKIEJARagain - I destruct the handle with
curl_easy_cleanup()
The last step used to write cookies to the cookiejar, but after the fd6eb8d it doesn't anymore.
I worked around this on my end by doing the reset before setting the options, but I still view this as a regression in curl which could affect my users if they upgrade libcurl without upgrading my software.
I expected the following
A curl handle that was used for HTTP transfers should write cookies into the cookie jar, even if that handle was reset with curl_easy_reset() after the transfer.
curl/libcurl version
curl 8.17 and newer
operating system
I reproduced this problem on the following platforms:
FreeBSD 14.3 with "latest" repositories
Arch Linux in a Podman container
Ubuntu 24.04.3 in a Podman container with curl built from source
Podman is running on Debian stable, uname -a: Linux dcf477645e4a 6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64 x86_64 x86_64 GNU/Linux