Bug #74988 [Opn->Nab]: DOMDocument::load() reports success but libxml_get_errors() return errors

From: Date: Tue, 25 Jul 2017 21:49:18 +0000
Subject: Bug #74988 [Opn->Nab]: DOMDocument::load() reports success but libxml_get_errors() return errors
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-210330@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74988&edit=1 ID: 74988 Updated by: requinix@php.net Reported by: paul at sparrowhawkcomputing dot com Summary: DOMDocument::load() reports success but libxml_get_errors() return errors -Status: Open +Status: Not a bug Type: Bug Package: DOM XML related Operating System: Windows 10 Pro PHP Version: 5.6.31 Block user comment: N Private report: N New Comment: If there is a bug here then it is not with PHP. It is with libxml. You'd have to report the problem there. But I don't see the problem. As you quoted, the processor may recover by reporting the erroneous value to the application - which is exactly what happened. Here's some formatting: "the XML processor - may report the error or - may recover by * ignoring the attribute specification or by * reporting the (erroneous) value to the application" Seems like you're interpreting it as "the XML processor may report the error or... by reporting the (erroneous) value to the application" but that doesn't make sense. > and libxml_clear_errors() should be called internally before DOMDocument::load() returns That would discard *all* errors during loading. A very bad idea. Previous Comments: ------------------------------------------------------------------------ [2017-07-25 21:09:49] paul at sparrowhawkcomputing dot com Description: ------------ Given the following XML document in test.xml: <?xml version="1.0"?> <root xml:space='foo'/> The script in the "Test Script" field below reports that the instance is loaded successfully while simultaneously reporting well-formedness errors. How can this instance be successfully loaded while there are well-formedness errors reported? Test script: --------------- libxml_use_internal_errors( true ); $dom = new DOMDocument(); libxml_clear_errors(); $success = $dom->load( __DIR__ . '/test.xml' ); $xml = $dom->saveXML(); $errs = libxml_get_errors(); var_dump( $success ); var_dump( $errs ); var_dump( $xml ); Expected result: ---------------- Either: $success == false && ! empty( $errs ) && $xml === '<?xml version="1.0"?>' or $success == true && empty( $errs ) && $xml === '<?xml version="1.0"?> <root/> ' That is, if libxml_get_errors() is going to return errors then DOMDocument::load() should return false. If DOMDocument::load() is going to succeed, then @xml:space should be ignored and libxml_clear_errors() should be called internally before DOMDocument::load() returns. Either alternative conforms to the XML spec, which says [1]: This specification does not give meaning to any value of xml:space other than "default" and "preserve". It is an error for other values to be specified; the XML processor may report the error or may recover by ignoring the attribute specification or by reporting the (erroneous) value to the application. Applications may ignore or reject erroneous values. The status quo does not conform to the XML spec because it both reports the error and fails to ignore the @xml:space attribute. I VERY MUCH prefer the first alternative, as it is consistent with XMLReader which correctly reports the well-formedness error and refuses to parse test.xml. [1] https://www.w3.org/TR/REC-xml/#sec-white-space Actual result: -------------- bool(true) array(1) { [0]=> object(LibXMLError)#260 (6) { ["level"]=> int(1) ["code"]=> int(102) ["column"]=> int(16) ["message"]=> string(69) "Invalid value "foo" for xml:space : "default" or "preserve" expected " ["file"]=> string(87) "file://test.xml" ["line"]=> int(2) } } string(80) "<?xml version="1.0"?> <root xml:space="foo"/> " ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74988&edit=1

« previous php.bugs (#210330) next »