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: bugreports 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: 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 Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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