|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #74868 CURLFile does not allow to create an object from a stream
Submitted: 2017-07-06 18:59 UTC Modified: 2020-03-16 08:37 UTC
From: vladshpilberg at gmail dot com Assigned:
Status: Re-Opened Package: cURL related
PHP Version: 7.0.21 OS:
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: vladshpilberg at gmail dot com
New email:
PHP Version: OS:


 [2017-07-06 18:59 UTC] vladshpilberg at gmail dot com
From manual page:

CURLFile does not allow to create an object from a stream, it always requires file to be saved on a server first, which is not very convenient. It definitely reads file to a stream somewhere under hood, why not allow to create it from a stream?

I, for example, have a task of reading file from AWS S3 and passing it to some API. I can do it 'old way' using @, but it's deprecated now and I have to save it to temp location on my server first, which gives me an unnecessary headache of storage management.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-07-06 21:15 UTC] hanskrentel at yahoo dot de
The example given is a bit mood as @ didn't support stream resources as well.

However most stream resources do have a file-path already, so this can be wrapped - for example:

 * Class CURLResource
 * CURLFile of a stream resource
class CURLResource extends CURLFile
    public function __construct(
        string $mimetype = null,
        string $postname = null)
        if (!(is_resource($resource) && 'stream' === get_resource_type($resource))) {
            throw new InvalidArgumentException('Not a stream resource');
        if (null === $filename = stream_get_meta_data($resource)['uri'] ?? null) {
            throw new InvalidArgumentException('Incompatible stream resource, "uri" metadata missing');
        parent::__construct($filename, $mimetype, $postname);

Externalized it is just:

new CURLFile(stream_get_meta_data($resource)['uri']);

This might already suffice for your example. If the resource closed automatically (e.g. one from tmpfile()), the resource handle has to be kept until the file has been send.

You can also post directly from a stream with curl, just not AFAIK for post form data encoded file uploads, but for the whole request body, see CURLOPT_INFILE,

For more options, just properly wrap . It should bring the (imagined) headaches to a minimum.

But with all the issues of hidden state a stream resource can come with, I wonder if it is really useful to have support for that in the extension itself. Handling of temporary files is much more straight forward, I wonder bit what the headaches are. Just my 2 cents.
 [2019-03-08 13:38 UTC] anrdaemon at freemail dot ru
I'd rather prefer CURLFile accepting resource handle directly.
Would save a lot of headache, including the issues of UNICODE names under Windows.
 [2020-03-11 14:38 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2020-03-11 14:38 UTC]
This is supported as of PHP 7.4.0 and libcurl 7.56.0 (it was a
requirement to implement feature request #77711), and is supposed
to work for all seeakable streams (non-seekable streams are
basically supported as well, but these may require chunked
uploads, which are not generally supported by Webservers, see bug
 [2020-03-12 16:53 UTC]
-Status: Closed +Status: Re-Opened
 [2020-03-12 16:53 UTC]
Oh, sorry, I've misread the request.  Stream resources are not
supported, only stream wrapper URLs.
 [2020-03-16 08:37 UTC]
-Assigned To: cmb +Assigned To:
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Jun 13 21:01:33 2024 UTC