php.net |  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
Have you experienced this issue?
Rate the importance of this bug to you:

 [2019-12-20 00:12 UTC] divinity76 at gmail dot com
Description:
------------
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" http://127.0.0.1:9999/

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:
---------------
<?php
$stupid_workaround_fileh = tmpfile();
$stupid_workaround_filef = stream_get_meta_data($stupid_workaround_fileh)['uri'];
fwrite($stupid_workaround_fileh,"{json}");
$ch=curl_init();
curl_setopt_array($ch, array(
    CURLOPT_URL => "http://127.0.0.1:9999/",
    CURLOPT_POST => 1,
    CURLOPT_POSTFIELDS => array(
        'uploadManifest' => new CURLFile($stupid_workaround_filef, 'application/json', '')
    )
));
curl_exec($ch);

Expected result:
----------------
POST / HTTP/1.1
Host: 127.0.0.1:9999
Accept: */*
Content-Length: 186
Content-Type: multipart/form-data; boundary=------------------------2e0011350c342f21

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

{json}
--------------------------2e0011350c342f21--


Actual result:
--------------
POST / HTTP/1.1
Host: 127.0.0.1:9999
Accept: */*
Content-Length: 214
Content-Type: multipart/form-data; boundary=------------------------2e0011350c342f21

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

{json}
--------------------------2e0011350c342f21--


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

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] cmb@php.net
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
documented[1]:

| (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] <https://www.php.net/manual/en/class.curlfile.php#curlfile.props.postname>
[2] <http://svn.php.net/viewvc?view=revision&revision=349387>
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Dec 02 16:01:23 2020 UTC