simplexml_load_string errors on big files occur on one system but not another

Question

I\'m dealing with a third party PHP library that I can\'t edit, and it\'s been working fine for almost a year. It uses simplexml_load_string on the response fro

Answer 1

Your XML is Invalid and should cause an issue in both cases.

You need to have ONLY ONE ROOT.

ie. Everything should be inside your tags:

<?xml version="1.0"?>
<RETS>
    ...
</RETS>

You have multiple roots in your XML, which will cause an issue :-)

Try wrapping it all in a root node and see if it works.

<?xml version="1.0"?>
<rootNode>
    <RETS>
    ...
    </RETS>
    <count bla="99" />
</rootNode>

I'm not sure if it would be the difference in libxml, or a different level of error reporting allowing it to work on one and not the other, but that looks like the issue to me.

Answer 2

The libxml2 changelog contains "608773 add a missing check in xmlGROW (Daniel Veillard)", which seems to be related to input buffering. Note I don't know anything about libxml2 internals, but it seems conceivable that you have tickled a 2.7.6 bug fixed in 2.7.7.

Check if the behavior is any different when you use simplexml_load_file() directly, and try setting libxml parser-related options, e.g.

simplexml_load_string($xml, 'SimpleXMLElement', LIBXML_COMPACT | LIBXML_PARSEHUGE)

Specifically, you might want to try the LIBXML_PARSEHUGE flag.

http://php.net/manual/en/libxml.constants.php
XML_PARSE_HUGE flag relaxes any hardcoded limit from the parser. This affects limits like maximum depth of a document or the entity recursion, as well as limits of the size of text nodes.

Answer 3

My XMLSpy confirmed that your XML file (which I downloaded from the link you provided) has no issues and is well-formed.

One potential issue however is the fact that the "encoding" attribute is missing from the XML preamble: Depending on your version of libxml2, I guess the following scenario might be possible: Server checks for encoding attribute, in lack of which server falls back to some default value (configuration setting). Maybe older library versions don't check the BOM.

Please also see this link, they had a similar encoding problem with libxml: https://stackoverflow.com/questions/4724241/utf-8-problems-with-php-dom-on-debian-server

the essence of which is that an upgrade of your libxml library might indeed solve the problem. Alternatively it might be worth checking the default encoding setting in the configuration.

According to my XMLSpy, the file is utf-8 encoded - as a test, maybe it's worth checking if specifying

<?xml version="1.0" encoding="UTF-8"?>

as the file preamble stops your Unix server from choking.