can we make curl_close() write CURLOPT_COOKIEJAR again?

[divinity76]

Description

The following code:

<?php
declare(strict_types=1);
$ch = curl_init();
$cookiefile_handle = tmpfile();
$cookiefile = stream_get_meta_data($cookiefile_handle)['uri'];
curl_setopt_array($ch, array(
    CURLOPT_COOKIEFILE => $cookiefile,
    CURLOPT_COOKIEJAR => $cookiefile,
    CURLOPT_WRITEFUNCTION => function ($ch, $str) {
        // echo $str;
        return strlen($str);
    },
));
curl_setopt($ch, CURLOPT_URL, "https://example.com/");
curl_exec($ch);
var_dump(file_get_contents($cookiefile));
curl_close($ch);
var_dump(file_get_contents($cookiefile));

will, prior to PHP8.0.0 result in:

$ php7.4 test.php
string(0) ""
string(131) "# Netscape HTTP Cookie File
# https://curl.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

and in >=8.0.0 result in

$ php8.2 test.php
string(0) ""
string(0) ""

which breaks scripts relying on curl_close() writing to CURLOPT_COOKIEJAR

• either we should make curl_close write to COOKIEJAR again, or we should at least add a note to https://www.php.net/manual/en/migration80.incompatible.php that you can no longer rely on curl_close to write to COOKIEJAR.
  random
• related stackoverflow post: https://stackoverflow.com/a/13800822/1067003

PHP Version

PHP 8.0.0

Operating System

No response

[damianwadley]

What versions of libcurl do you have for your 7.4 and 8.0 (8.2?) setups?

[divinity76]

i think that is irrelevant, but it's 7.81.0 both of them:

$ php7.4 -r 'var_dump(curl_version());'
array(16) {
  ["version_number"]=>
  int(479488)
  ["age"]=>
  int(9)
  ["features"]=>
  int(364890013)
  ["ssl_version_number"]=>
  int(0)
  ["version"]=>
  string(6) "7.81.0"
  ["host"]=>
  string(19) "x86_64-pc-linux-gnu"
  ["ssl_version"]=>
  string(13) "OpenSSL/3.0.2"
  ["libz_version"]=>
  string(6) "1.2.11"
  ["protocols"]=>
  array(25) {
    [0]=>
    string(4) "dict"
    [1]=>
    string(4) "file"
    [2]=>
    string(3) "ftp"
    [3]=>
    string(4) "ftps"
    [4]=>
    string(6) "gopher"
    [5]=>
    string(7) "gophers"
    [6]=>
    string(4) "http"
    [7]=>
    string(5) "https"
    [8]=>
    string(4) "imap"
    [9]=>
    string(5) "imaps"
    [10]=>
    string(4) "ldap"
    [11]=>
    string(5) "ldaps"
    [12]=>
    string(4) "mqtt"
    [13]=>
    string(4) "pop3"
    [14]=>
    string(5) "pop3s"
    [15]=>
    string(4) "rtmp"
    [16]=>
    string(4) "rtsp"
    [17]=>
    string(3) "scp"
    [18]=>
    string(4) "sftp"
    [19]=>
    string(3) "smb"
    [20]=>
    string(4) "smbs"
    [21]=>
    string(4) "smtp"
    [22]=>
    string(5) "smtps"
    [23]=>
    string(6) "telnet"
    [24]=>
    string(4) "tftp"
  }
  ["ares"]=>
  string(0) ""
  ["ares_num"]=>
  int(0)
  ["libidn"]=>
  string(5) "2.3.2"
  ["iconv_ver_num"]=>
  int(0)
  ["libssh_version"]=>
  string(25) "libssh/0.9.6/openssl/zlib"
  ["brotli_ver_num"]=>
  int(16777225)
  ["brotli_version"]=>
  string(5) "1.0.9"
}
$ php8.2 -r 'var_dump(curl_version());'
array(16) {
  ["version_number"]=>
  int(479488)
  ["age"]=>
  int(9)
  ["features"]=>
  int(364890013)
  ["ssl_version_number"]=>
  int(0)
  ["version"]=>
  string(6) "7.81.0"
  ["host"]=>
  string(19) "x86_64-pc-linux-gnu"
  ["ssl_version"]=>
  string(13) "OpenSSL/3.0.2"
  ["libz_version"]=>
  string(6) "1.2.11"
  ["protocols"]=>
  array(25) {
    [0]=>
    string(4) "dict"
    [1]=>
    string(4) "file"
    [2]=>
    string(3) "ftp"
    [3]=>
    string(4) "ftps"
    [4]=>
    string(6) "gopher"
    [5]=>
    string(7) "gophers"
    [6]=>
    string(4) "http"
    [7]=>
    string(5) "https"
    [8]=>
    string(4) "imap"
    [9]=>
    string(5) "imaps"
    [10]=>
    string(4) "ldap"
    [11]=>
    string(5) "ldaps"
    [12]=>
    string(4) "mqtt"
    [13]=>
    string(4) "pop3"
    [14]=>
    string(5) "pop3s"
    [15]=>
    string(4) "rtmp"
    [16]=>
    string(4) "rtsp"
    [17]=>
    string(3) "scp"
    [18]=>
    string(4) "sftp"
    [19]=>
    string(3) "smb"
    [20]=>
    string(4) "smbs"
    [21]=>
    string(4) "smtp"
    [22]=>
    string(5) "smtps"
    [23]=>
    string(6) "telnet"
    [24]=>
    string(4) "tftp"
  }
  ["ares"]=>
  string(0) ""
  ["ares_num"]=>
  int(0)
  ["libidn"]=>
  string(5) "2.3.2"
  ["iconv_ver_num"]=>
  int(0)
  ["libssh_version"]=>
  string(25) "libssh/0.9.6/openssl/zlib"
  ["brotli_ver_num"]=>
  int(16777225)
  ["brotli_version"]=>
  string(5) "1.0.9"
}

[KapitanOczywisty]

https://www.php.net/manual/en/function.curl-close.php

Note:
This function has no effect. Prior to PHP 8.0.0, this function was used to close the resource.

Try unset($ch); instead of curl_close($ch); :)

[cmb69]

That! As of PHP 8.0.0, curl_close() is a no-op; that is already documented. The closest pendant as of PHP 8.0.0 is to destroy the object. Maybe we should clarify this in the docs.

[KapitanOczywisty]

@cmb69 Maybe curl_close should be deprecated? There is no reason to keep it around and it's not the first time I've seen confusion about curl_close. FWIW before 8.0 unset($ch) had the same effect as curl_close($ch) and even in older versions could be used instead.

[cmb69]

Maybe curl_close should be deprecated? There is no reason to keep it around and it's not the first time I've seen confusion about curl_close. FWIW before 8.0 unset($ch) had the same effect as curl_close($ch) and even in older versions could be used instead.

There is a subtle difference. Unsetting a variable of resource type decreases the refcount, and only if that drops to zero, the resource is destroyed. Closing a resource is unrelated to the refcount, but the underlying "object" is always closed (e.g. https://3v4l.org/1pR91). While a resource itself is pretty lightweight, the underlying "object" might not (it may keep a database connection open, for instance). Existing code might rely on this.

So I'm not sure whether we should deprecate that function (and other functions which changed analogously) yet. Maybe it's better to wait a couple of years?

[KapitanOczywisty]

There is a subtle difference. Unsetting a variable of resource type decreases the refcount, and only if that drops to zero, the resource is destroyed.

I've made a bit of simplification: curl handle is rarely curl_closed and kept around in global/shared variable at the same time, so in most cases effect is exactly the same - underlying curl data are destroyed. If somebody has curl_close on variable, but is keeping other references it is most likely an error, so deprecation would even help. For example if library is using the same code since 7.4 it might now unintentionally occupy resources.
My thinking was that one could change code in a way that it would work in all versions the same way, if support wider range of php versions was needed, but this also wouldn't very common anyway, especially after ending active support for 8.0.

So I'm not sure whether we should deprecate that function (and other functions which changed analogously) yet. Maybe it's better to wait a couple of years?

Of course deprecation will generate a few deprecation message and annoy people with old code, but It has to be done someday. People are still putting curl_close in newer code in php-src ^[1][2] not to mention places like stackoverflow where copy/paste is more prominent.

[volkerschulz]

The documentation on curl_setopt still states

The name of a file to save all internal cookies to when the handle is closed, e.g. after a call to curl_close.

which is misleading at least, because curl_close does not close the handle (and therefore doesn't save the cookie file) with PHP >= 8.0.0. Also see the discussion at https://stackoverflow.com/questions/77260319/curl-close-not-writing-curlopt-cookiejar-session-file-from-php-8-onwards/77261355#77261355