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: christian at klemmer dot io 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: 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 Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2019-12-22 21:21:50] bugreports at gmail dot com a) Curl prefers HTTP/2 when the sevrer supports it b) the server of the reporter support HTTP2 as he statet c) that below is curl against a http2 proxy with a http1 backend the origin sned all the headers in the style of "Cache-Control" and the proxy talking http2 transofrms them to lowercase curl --head https://localhost/ HTTP/2 200 date: Sun, 22 Dec 2019 21:19:35 GMT strict-transport-security: max-age=31536000 x-frame-options: SAMEORIGIN etag: 786c872ae3730afa5623a43d8ee3e38b cache-control: private last-modified: Mon, 28 Nov 2016 16:55:29 GMT vary: Accept-Encoding,User-Agent content-type: text/html; charset=ISO-8859-1 age: 0 ------------------------------------------------------------------------ [2019-12-22 21:15:31] requinix@php.net Thing is, this doesn't make any sense. 1. I can't imagine cURL will use HTTP/2 without an Upgrade or explicit foreknowledge about remote support for it 2. I would also expect it to use HTTP/2 only if the passed options supported it (at least until it's more common) 3. Like I said, the headers are completely wrong I only really see two possibilities: either something in this bug report is incorrect, or cURL has some sort of massive bug(s) regarding HTTP/2 support that nobody seems to have noticed until now. No offense but from where I'm sitting, only one of those is believable. As for reproducing, On Ubuntu with libcurl 7.58 I get a chunked HTTP/1.1 request with PHP 7.4.1 and an unchunked HTTP/1.1 request with PHP 7.3.13, so if something changed in cURL it was between 7.58 and 7.64. ------------------------------------------------------------------------ [2019-12-22 20:47:02] christian at klemmer dot io Yes, it's 100% the same script. After writing down my reposcript I actually posted a little file to https://example.com/ to test if it's working there also. It is. And https://example.com/ is also showing with HTTP/2 in Google Chrome, so I think it's capable of doing so. ------------------------------------------------------------------------ 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