Documented at http://www.php.net/manual/en/wrappers.data.php

Dear vrana,

This is incorrect. Either the documentation or the behaviour is broken.

The documentation states:

Restricted by allow_url_fopen  	No

This bug still exists. I am calling

$res = fopen('data://text/plain;base64,' . base64_encode($value), 'r');

And getting this error log: PHP Warning:  fopen(): data:// wrapper is disabled in the server configuration by allow_url_fopen=0 in /var/www/htdocs/src/Acme/Component/Doctrine/DBAL/Types/Mediumblob.php on line 27

$ php -v
PHP 5.3.3-7+squeeze15 with Suhosin-Patch (cli) (built: Mar  4 2013 13:11:17)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

This bug is still valid: reading https://www.php.net/manual/en/wrappers.data.php it seems that the data:// stream wrapper is not affected by the allow_url_fopen INI value set to false.

By the way, it seems that if allow_url_fopen is false, the stream wrapper is disabled.

I executed the command line described in the "Test script" section in the following environments, and they all fail (they report the "data:// wrapper is disabled" warning):

- PHP 7.2.24 on Ubuntu 18.04.3
- PHP 7.4.0 on Windows 10 1909
- PHP 7.3.12 on Windows 10 1909
- PHP 7.2.25 on Windows 10 1909
- PHP 7.1.33 on Windows 10 1909
- PHP 7.0.33 on Windows 10 1909
- PHP 5.6.40 on Windows 10 1909
- PHP 5.5.38 on Windows 10 1909
- PHP 5.4.45 on Windows 10 1909
- PHP 5.3.29 on Windows 10 1909
- PHP 5.2.17 on Windows 10 1909

Is this a documentation issue? Or the manual describes the wanted behavior but the implementation is wrong?
IMHO what's described in the documentation is to be preferred...


# Test script:

php -n -d allow_url_fopen=0 -r "echo in_array('data', stream_get_wrappers()) ? file_get_contents('data://text/plain,test') : 'not available';"


# Expected result:
test

# Actual result:
Warning: file_get_contents(): data:// wrapper is disabled in the server configuration by allow_url_fopen=0 in Command line code on line 1

I know this has been dormant for a while, but it continues to be a practical issue 15 years on from when it was begun, and it would be great if it could be moved forward.

In the last week I've had to modify some code after finding that this issue prevents a simple local server operation from operating on a server that the system administrators have "secured". 

My code extracts rotation information from EXIF data saved in images generated by phones etc. as part of a wider image processing utility.

To extract the EXIF data I'm using exif_read_data() and this utility only accepts file based inputs. So, as is commonly done, I'm using the data:// wrapper to convert an image that is already in memory to a form that works with exif_read_data() - this sort of thing:

exif_read_data('data://' . $mime . ';base64,' . base64_encode($data), null, true, false)

This makes no use of remote files yet is prevented from operating on the secured server by the data:// requirement for allow_url_fopen.

Suggesting to a sysadmin that they make their server less secure so that an image utility that has no actual need to contact a remote server can correct the rotation of an iPhone image (that was itself read from a local disk) seems like a request that is unlikely to be satisfied.

A better solution if it is possible would be to remove the requirement for allow_url_fopen from use of data://.