Bug #79013 [Com]: Content-Length missing when posting a curlFile with curl

Edit report at https://bugs.php.net/bug.php?id=79013&edit=1 ID: 79013 Comment by: sdmarshall73 at gmail dot com Reported by: christian at klemmer dot io Summary: Content-Length missing when posting a curlFile with curl Status: Assigned Type: Bug Package: cURL related Operating System: debian 10.2 PHP Version: 7.4.1 Assigned To: cmb Block user comment: N Private report: N New Comment: My apologies for the previous post ( and this one ). You did mention the files were being removed on the remote side. Seems like the same issue I'm experiencing. I've voted on the bug and I'll just follow this post. Please remove these comments if possible. Previous Comments: ------------------------------------------------------------------------ [2020-01-23 17:10:05] sdmarshall73 at gmail dot com Have you actually tested to see if the files are being received on the remote server? I have an application that uploads files and the files aren't being received on the remote server when using PHP7.4. I wanted to see if this bug is related before filing my own bug report. ------------------------------------------------------------------------ [2019-12-23 08:54:46] cmb@php.net Thanks for reporting and digging into the details! In my opinion, no longer sending a Content-Length header but instead falling back to chunked transfer encoding is a bug at least for PHP 7.3, where request #77711 has recently been back-ported to[1]. For PHP 7.4, this change might be acceptable, but would at least have to be documented. However, while having a closer look at this issue, I've noticed that the current implementation can't really work wrt. curl_copy_handle()[2], what has to be addressed first, since fixing that will result in a quite different implementation, which renders the obvious trivial fix for this issue moot. > So it seems to be a combination of several CURL versions with > PHP 7.4 To clarify, this issue affects only libcurl >= 7.56.0, since older versions still use the "classic" file upload. [1] <http://git.php.net/?p=php-src.git;a=commit;h=17a9f1401aeb35fe1e3657b38102a410d151d42f> [2] <https://bugs.php.net/bug.php?id=79019> ------------------------------------------------------------------------ [2019-12-22 22:41:03] christian at klemmer dot io And as addition tests with PHP 7.3.13 with different curl versions. All result in the expected behaviour. Ubuntu 19.10 - PHP 7.3.13 - CURL 7.65.3 (7.65.3-1ubuntu3): ----------------------- POST / HTTP/2 Host: example.com Accept: */* Content-Length: 210 Content-Type: multipart/form-data; boundary=------------------------4d274c175c3e77e5 Debian 9.11 - PHP 7.3.13 - CURL 7.52.1 (7.52.1-5+deb9u9): ----------------------- POST / HTTP/1.1 Host: example.com Accept: */* Content-Length: 210 Expect: 100-continue Content-Type: multipart/form-data; boundary=------------------------5652b6f1c9e7a818 Debian 10.2 - PHP 7.3.13 - CURL 7.64.0 (7.64.0-4): ----------------------- POST / HTTP/2 Host: example.com Accept: */* Content-Length: 210 Content-Type: multipart/form-data; boundary=------------------------0b86b20895500f64 So it seems to be a combination of several CURL versions with PHP 7.4 ------------------------------------------------------------------------ [2019-12-22 22:14:47] christian at klemmer dot io I did some additional testing with some VMs: Ubuntu 19.10 - PHP 7.4.1 - CURL 7.65.3 (7.65.3-1ubuntu3): ----------------------- POST / HTTP/2 Host: example.com Accept: */* Transfer-Encoding: chunked Content-Type: multipart/form-data; boundary=------------------------d498818044360b85 Debian 9.11 - PHP 7.4.1 - CURL 7.52.1 (7.52.1-5+deb9u9): ----------------------- POST / HTTP/1.1 Host: example.com Accept: */* Content-Length: 210 Expect: 100-continue Content-Type: multipart/form-data; boundary=------------------------a4980090fbc4beae Debian 10.2 - PHP 7.4.1 - CURL 7.64.0 (7.64.0-4) (same versions as my initial bug report, but different machine): ----------------------- POST / HTTP/2 Host: example.com Accept: */* Transfer-Encoding: chunked Content-Type: multipart/form-data; boundary=------------------------f8e60d58d7f0df39 Here are the steps to reproduce my exact test environment: Install Debian 10.2 (buster). apt install apt-transport-https lsb-release ca-certificates curl -fsSL https://packages.sury.org/php/apt.gpg | apt-key add - sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" >> /etc/apt/sources.list' apt update apt install php7.4-bcmath php7.4-bz2 php7.4-cgi php7.4-cli php7.4-common php7.4-curl php7.4-dba php7.4-fpm php7.4-gd php7.4-imagick php7.4-imap php7.4-intl php7.4-json php7.4-ldap php7.4-mbstring php7.4-mysql php7.4-readline php7.4-soap php7.4-xml php7.4-zip ------------------------------------------------------------------------ [2019-12-22 21:38:10] requinix@php.net Ah, I didn't know HTTP/2 support was indicated in the TLS handshake. That explains some. So I'm back to the headers being wrong. Maybe I just don't have the right environment to test this. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=79013 -- Edit this bug report at https://bugs.php.net/bug.php?id=79013&edit=1