Fresh Contao installation -> XMLReader::open(): Argument #1 ($uri) must not contain any null bytes

[jochi44]

Affected version(s)

4.13.16
5.1.0

Description

I just installed Contao 4.13.16 via Contao Manager (PHP 8.2.3).
When clicking on any menu item in the backend (e.g. Articles), I get an internal server error:

XMLReader::open(): Argument #1 ($uri) must not contain any null bytes

Stack Trace (Debug modus ON):

Exception ValueError in [vendor/contao/image/src/Image.php ](https://abc.tld/_profiler/open?file=vendor/contao/image/src/Image.php&line=216#line216)(line 216) Symfony Exception [Symfony Docs](https://symfony.com/doc/5.4.21/index.html) [UndefinedFunctionError](https://abc.tld/contao?do=files&ref=fPU9t8Ir#trace-box-1) HTTP 500 Internal Server Error Attempted to call function "highlight_file" from namespace "Symfony\Component\ErrorHandler\ErrorRenderer". Did you mean to call "\safe\highlight_file"? Exception Symfony\Component\ErrorHandler\Error\ UndefinedFunctionError in [/var/www/web/vendor/symfony/error-handler/ErrorRenderer/HtmlErrorRenderer.php ](https://abc.tld/contao?do=files&ref=fPU9t8Ir)(line 271)

[ausi]

Can you please test what the output of the following PHP code is on your system?

var_dump((new \XMLReader)->open('compress.zlib://data:text/xml,<x/>'));

[jochi44]

The output is
bool(true)

[jochi44]

This is definitely a PHP 8.2.3 issue.
With PHP version 8.1.16 the error does not occur.

[ausi]

The output is
bool(true)

This is intresting, because that code is exactly whats happening on line 216 in Image.php.
Can you please check what code is executed in your vendor/contao/image/src/Image.php on line 216?

This is definitely a PHP 8.2.3 issue.

So the output for PHP 8.2.3 is not bool(true)?

[jochi44]

Can you please check what code is executed in your vendor/contao/image/src/Image.php on line 216?

Line 216 is && true === @$reader->open('compress.zlib://data:text/xml,<x/>')

So the output for PHP 8.2.3 is not bool(true)?

Output for both, php 8.1.16 and php 8.2.3 is bool(true)

The error also occurs in Contao 5.1.0 (error with php 8.2.3, no error with php 8.1.16).

Additional notes:
To test the command var_dump((new \XMLReader)->open('compress.zlib://data:text/xml,<x/>')); I created a test.php file on the server.
When running it with the php-7.4 CLI-binary I get: bool(true)
When running it with the php-8.1 CLI-binary I get: bool(true)
When running it with the php-8.2 CLI-binary I get: PHP Fatal error: Uncaught ValueError: XMLReader::open(): Argument #1 ($uri) cannot be empty in /var/www/web/test.php:2 Stack trace: #0 /var/www/web/test.php(2): XMLReader->open() #1 {main} thrown in /var/www/web/test.php on line 2

[ausi]

You wrote

Output for both, php 8.1.16 and php 8.2.3 is bool(true)

and

When running it with the php-8.2 CLI-binary I get: PHP Fatal error: Uncaught ValueError: XMLReader::open(): Argument #1 ($uri) cannot be empty in /var/www/web/test.php:2 Stack trace: #0 /var/www/web/test.php(2): XMLReader->open() #1 {main} thrown in /var/www/web/test.php on line 2

So which is it for PHP 8.2, bool(true) or PHP Fatal error…?

[jochi44]

On the CLI
/opt/php-7.4/bin/php test.php is bool(true)
/opt/php-8.1/bin/php test.php is bool(true)
/opt/php-8.2/bin/php test.php is PHP Fatal error: Uncaught ValueError: XMLReader::open(): Argument #1 ($uri) cannot be empty in /var/www/web/test.php:2 Stack trace: #0 /var/www/web/test.php(2): XMLReader->open() #1 {main} thrown in /var/www/web/test.php on line 2

[ausi]

I’m not able to reproduce the PHP Fatal error, can you please also try the following in your PHP 8.2 setup:

var_dump((new \XMLReader)->open('data:text/xml,<x/>'));
var_dump((new \XMLReader)->open('data:text/xml;base64,PHgvPg=='));

$file = tempnam(sys_get_temp_dir(), 'xml');
file_put_contents($file, '<x/>');
var_dump((new \XMLReader)->open($file));

[jochi44]

web1@s1:/var/www/web/templates$/opt/php-8.2/bin/php test2.php PHP Fatal error: Uncaught ValueError: XMLReader::open(): Argument #1 ($uri) cannot be empty in /var/www/web/templates/test2.php:2 Stack trace: #0 /var/www/web/templates/test2.php(2): XMLReader->open() #1 {main} thrown in /var/www/web/templates/test2.php on line 2 web1@s1:/var/www/web/templates$

I am running this on an nginx server.
php-details:

web1@s1:/var/www/web/templates$ /opt/php-8.2/bin/php --version PHP 8.2.3 (cli) (built: Feb 20 2023 18:24:06) (NTS) Copyright (c) The PHP Group Zend Engine v4.2.3, Copyright (c) Zend Technologies with Zend OPcache v8.2.3, Copyright (c), by Zend Technologies web1@s1:/var/www/web/templates$

[ausi]

Very strange. It seems like the data: protocol is broken in your installation. But it doesn’t seem to be disabled because in that case the error message would read XMLReader::open(): Unable to find the wrapper "data"

One last test code to execute please:

var_dump(file_get_contents('data:text/xml;base64,PHgvPg=='));
var_dump(file_get_contents('data:text/xml,<x/>'));

If this does not output string(4) "<x/>" twice, your PHP setup probably needs to be fixed.
(For reference, this should work everywhere: https://3v4l.org/Wr0gF )

[jochi44]

The output of

var_dump(file_get_contents('data:text/xml;base64,PHgvPg=='));
var_dump(file_get_contents('data:text/xml,<x/>'));

is

web5@s1:/var/www/web/templates$ php test3.php
string(4) "<x/>"
string(4) "<x/>"
web5@s1:/var/www/web/templates$ /opt/php-8.1/bin/php test3.php
string(4) "<x/>"
string(4) "<x/>"
web5@s1:/var/www/web/templates$ /opt/php-8.2/bin/php test3.php
string(4) "<x/>"
string(4) "<x/>"
web5@s1:/var/www/web/templates$

[jochi44]

@ausi the error still persists with php 8.2.5 (on a fresh contao 4.13 installation).
Should I get in contact with the hoster regarding this issue?

[ausi]

Should I get in contact with the hoster regarding this issue?

Yes, I think this would make sense. You can point them to https://3v4l.org/djBF9 that shows this example code works without errors in other PHP setups.

[macearl]

This seems to be an issue with older libxml2 Versions, we are experiencing the same problem on Debian 10 / libxml2=2.9.4 and Debian 11 / libxml=2.9.10

The packages provided by @oerdnj / https://deb.sury.org/ also have this problem, which is not surprising as he is or at least was a Debian Developer/Packager

A self-compiled PHP 8.2 with libxml2=2.10.14 seems to work, i'm not too familiar with the debian issue tracker, but perhaps we should raise an issue there, so that the newer libxml which is used in bookworm and is also provided by @oerdnj for buster / bullseye could get backported to buster/bullseye

[ausi]

I don’t think it is related to libxml version 2.9.4 as 3v4l.org uses the same version, see https://3v4l.org/3NCuc

@macearl what is the output of the following code snippet on your system?

<?php

echo "libxml ".LIBXML_DOTTED_VERSION."\n\n";

var_dump((new \XMLReader)->open('data:text/xml,<x/>'));
var_dump((new \XMLReader)->open('data:text/xml;base64,PHgvPg=='));

[macearl]

mmh it seems I did not Check the Version from sury correctly, as it also uses the newer libxml2. The libxml2 Version was the only thing we changed in our versions, maybe it's a Debian thing? @jochi44 which OS do you guys use?

php8.2 is from the sury repo, /opt/php-8.2 is our self compiled 8.2 with the default Debian libxml2 and /opt/php-8.2.8 is another self compiled version which used the same options and the only difference was that we previously installed the newer libxml2 from the sury repo.

user@bullseyehost ~ # /opt/php-8.2/bin/php xmltest.php 
libxml 2.9.10

PHP Fatal error:  Uncaught ValueError: XMLReader::open(): Argument #1 ($uri) cannot be empty in /home/user/xmltest.php:5
Stack trace:
#0 /home/user/xmltest.php(5): XMLReader->open()
#1 {main}
  thrown in /home/user/xmltest.php on line 5

user@bullseyehost ~ # php8.2 xmltest.php 
libxml 2.9.14

PHP Fatal error:  Uncaught ValueError: XMLReader::open(): Argument #1 ($uri) cannot be empty in /home/user/xmltest.php:5
Stack trace:
#0 /home/user/xmltest.php(5): XMLReader->open()
#1 {main}
  thrown in /home/user/xmltest.php on line 5

user@bullseyehost ~ # /opt/php-8.2.8/bin/php xmltest.php 
libxml 2.9.14

bool(true)
bool(true)
user@bullseyehost ~ # lsb_release -c
Codename: bullseye

Here on a buster machine (I did not compile another version for this one):

user@busterhost ~ $ /opt/php-8.2/bin/php xmltest.php 
libxml 2.9.4

PHP Fatal error:  Uncaught ValueError: XMLReader::open(): Argument #1 ($uri) cannot be empty in /home/user/xmltest.php:5
Stack trace:
#0 /home/user/xmltest.php(5): XMLReader->open()
#1 {main}
  thrown in /home/user/xmltest.php on line 5
user@busterhost ~ $ lsb_release -c
Codename: buster

And on a bookworm host, which by default uses a newer libxml2

user@bookwormhost ~$ php8.2 xmltest.php 
libxml 2.9.14

bool(true)
bool(true)
user@bookwormhost ~$ lsb_release -c
No LSB modules are available.
Codename: bookworm

[ausi]

@macearl I think you could report this as a PHP bug then: https://github.com/php/php-src/issues/new/choose

[jochi44]

@macearl we are using "Debian GNU/Linux 10 (buster)".

[jr-timme]

We were also experiencing this issue and have found a possible solution.
For us, it had nothing to do with the libxml2 Version, which we also investigated first, but instead with the Tideways PHP Module which we also deploy on all our servers.

Disabling the flag tideways.features.observer resolves this issue on our servers. In case you are also using the Tideways Module try disabling this flag, or ask your Hoster to disable it for you.

[ausi]

@jochi44 @macearl do you also have the tideways-php extension installed on your systems?
If so, please try if the ini setting tideways.features.observer=0 fixes your issue.

[Toflar]

/cc @beberlei just FYI, Benjamin, in case you haven't heard of this issue in Tideways yet. Maybe it's also something that has been fixed already in a later version? :)

[macearl]

Disabling tideways.features.observer seems to have fixed the issue on our systems as well.

That also explains why it worked on our bookworm host as that is the only system without Tideways.

[beberlei]

@Toflar thanks for the ping, this is a known issue in PHP Observer API itself starting with PHP 8.2.0. It will crash with any extension using the observer API. The fix will be included in PHP 8.2.9 See php/php-src@cad47be

[Toflar]

Thank you so much for the feedback! ❤️ So updating to the upcoming PHP version 8.2.9 should fix the problem for everybody 😊
I think we may close this issue then?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.