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