|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79004 CURLFile's 3rd argument doesn't honor emptystring
Submitted: 2019-12-20 00:12 UTC Modified: 2020-03-12 09:17 UTC
From: divinity76 at gmail dot com Assigned:
Status: Open Package: cURL related
PHP Version: 7.2.26 OS: Ubuntu 18.04
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: divinity76 at gmail dot com
New email:
PHP Version: OS:


 [2019-12-20 00:12 UTC] divinity76 at gmail dot com
if you give CURLFile's an empty string as the third argument, it will in fact swap out the empty string with the first argument!

that makes porting this curl command rather difficult:

curl -F "uploadManifest={json};type=application/json"

i guess it's debatable weather emptystring should remove the filename header entirely (like CURLOPT_HTTPHEADER does, for example to remove libcurl-generated "Expect: 100-continue" headers, set CURLOPT_HTTPHEADER=>array("Except: "), and the Expect header won't be generated at all), or if it should literally send filename=""
(but my personal opinion is that it should work the same as CURLOPT_HTTPHEADER, eg remove the filename header entirely), but whatever the right action is, it's certainly not the current action of replacing it with the on-disk file-location, and that's what it's currently doing. (maybe that would be ok if argument 3 is null, i don't know, but it's not appropriate if the 3rd argument is emptystring, the programmer specifically asked for an empty filename, and now doesn't get one.)

Test script:
$stupid_workaround_fileh = tmpfile();
$stupid_workaround_filef = stream_get_meta_data($stupid_workaround_fileh)['uri'];
curl_setopt_array($ch, array(
    CURLOPT_URL => "",
    CURLOPT_POST => 1,
        'uploadManifest' => new CURLFile($stupid_workaround_filef, 'application/json', '')

Expected result:
Accept: */*
Content-Length: 186
Content-Type: multipart/form-data; boundary=------------------------2e0011350c342f21

Content-Disposition: form-data; name="uploadManifest"
Content-Type: application/json


Actual result:
Accept: */*
Content-Length: 214
Content-Type: multipart/form-data; boundary=------------------------2e0011350c342f21

Content-Disposition: form-data; name="uploadManifest"; filename="/tmp/phpSh32lX"
Content-Type: application/json



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2019-12-20 00:13 UTC] divinity76 at gmail dot com
-Package: Unknown/Other Function +Package: cURL related
 [2019-12-20 00:13 UTC] divinity76 at gmail dot com
change to curl-related (couldn't find "curl related" when creating the issue for some reason)
 [2019-12-20 00:20 UTC] divinity76 at gmail dot com
i suppose it's possible that the on-disk location of CURLFile's argument could be considered sensitive information, and thus it's inappropriate disclosure here may be a security issue, idk but food for thought
 [2020-03-12 09:17 UTC]
Well, I don't think that qualifies as security issue; it's not the
same as browsers sending the full filename, and the behavior is

| (defaults to the name property)

And although the documentation is not yet[2] explicit about the
default value, it's not hard to find out the default (which is an
empty string, not NULL).  However, there is the glitch that the
postname property is untyped, and anything else than a non empty
string causes the name property to be sent as postname.

Anyhow, I'm having a hard time to treat this as not a bug (or mere
documentation issue, or feature request).  Using basename(name) as
default would be way more reasonable, but as of PHP 7.4.0 stream
wrappers are supported, so that's not really an option.  Not
sending the filename attribute might be the most sensible choice,
but would be a BC break, so I'm not sure about that.

[1] <>
[2] <>
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed May 12 12:01:24 2021 UTC