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

Edit report at https://bugs.php.net/bug.php?id=79013&edit=1 ID: 79013 Updated by: requinix@php.net 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: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2019-12-22 20:39:52] requinix@php.net But are you actually using HTTP/2? Sure, your example says "HTTP/2" in it, but the headers themselves are HTTP/1. Is your repro script the same as what you posted here? ------------------------------------------------------------------------ [2019-12-22 12:49:48] christian at klemmer dot io Reading a bit more about it, I'm not sure if "Transfer-Encoding: chunked" is allowed, when using HTTP/2. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding "HTTP/2 doesn't support HTTP 1.1's chunked transfer encoding mechanism, as it provides its own, more efficient, mechanisms for data streaming." ------------------------------------------------------------------------ [2019-12-21 20:46:21] requinix@php.net Note that there's nothing inherently wrong with this behavior. Honestly, I think the bug is that your proxy somehow isn't allowing the file upload when it comes chunked instead of in full. I suggest looking into that. Anyway, looks like this change happened during request #77711 https://github.com/php/php-src/commit/c68dc6b5e37e74d89e0a387079139c054c8faa81 where using a CURLFile opts into cURL's support for streams, and it can't know the stream length so it has no choice but to go chunked. ------------------------------------------------------------------------ [2019-12-21 16:19:43] christian at klemmer dot io Description: ------------ When posting a curlFile with curl, I get different results with the same code (and curlFile) if I run it with PHP 7.3 or PHP 7.4. "Content-Length" is missing and instead replaced by "Transfer-Encoding: chunked". I query an API which is behind an haproxy server. Missing content-lenght seems to remove all files posted on their side. Nevertheless I would've expected the same behaviour with PHP 7.4 running with the same curl-version. I'm using the deb.sury.org repository on a debian 10.2 server. dpkg -l | grep curl ii curl 7.64.0-4 ii libcurl3-gnutls:amd64 7.64.0-4 ii libcurl4:amd64 7.64.0-4 ii php7.3-curl 7.3.13-1+0~20191218.50+debian10~1.gbp23c2da ii php7.4-curl 7.4.1-1+0~20191218.8+debian10~1.gbp21c50e ii python3-pycurl 7.43.0.2-0.1 curl-information out of phpinfo (7.3 testenv and 7.4 testenv are exactly the same): cURL support enabled cURL Information 7.64.0 Age 4 Features: AsynchDNS Yes CharConv No Debug No GSS-Negotiate No IDN Yes IPv6 Yes krb4 No Largefile Yes libz Yes NTLM Yes NTLMWB Yes SPNEGO Yes SSL Yes SSPI No TLS-SRP Yes HTTP2 Yes GSSAPI Yes KERBEROS5 Yes UNIX_SOCKETS Yes PSL Yes HTTPS_PROXY Yes MULTI_SSL No BROTLI No Protocols dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, ldaps, pop3, pop3s, rtmp, rtsp, scp, sftp, smb, smbs, smtp, smtps, telnet, tftp Host x86_64-pc-linux-gnu SSL Version OpenSSL/1.1.1d ZLib Version 1.2.11 libSSH Version libssh2/1.8.0 Test script: --------------- $filename = 'testfile.txt'; if(file_exists($filename) && is_file($filename) && (int)filesize($filename) > 0) { try { $ch = curl_init('https://example.com/') or die('API down'); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HEADER, true); curl_setopt($ch, CURLINFO_HEADER_OUT, true); curl_setopt($ch, CURLOPT_VERBOSE, true); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, array('test' => new CurlFile($filename))); curl_exec($ch); $curlInfo = curl_getinfo($ch); echo '<pre>'; print_r($curlInfo["request_header"]); echo '</pre>'; curl_close($ch); } catch(Exception $e) { echo $e->getMessage(); } } Expected result: ---------------- With PHP 7.3.13: POST / HTTP/2 Host: example.com Accept: */* Content-Length: 245 Content-Type: multipart/form-data; boundary=------------------------c129897ae3ed733b Actual result: -------------- With PHP 7.4.1: POST / HTTP/2 Host: example.com Accept: */* Transfer-Encoding: chunked Content-Type: multipart/form-data; boundary=------------------------ef5ab6d1e2455a47 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=79013&edit=1