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
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.
Password:
Status:
Package:
Bug Type:
Summary:
From: divinity76 at gmail dot com
New email:
PHP Version: OS:

 

 [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>
 [2023-04-26 08:50 UTC] austinpatrick711 at gmail dot com
The third argument of CURLFile is used to specify the name of the file being uploaded. However, it has been reported that CURLFile does not honor an empty string as a valid value for this argument. This means that if you pass an empty string as the third argument, the file name may not be set correctly when the file is uploaded.

It's important to note that CURLFile is a PHP class used for uploading files using the cURL library. (https://www.tellhappystar.net/)github.com
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 15:01:28 2024 UTC