Because we check the list with dom_sanity_check_node_list_for_insertion()
before dom_is_node_in_list(), then we don't have to check the object
type anymore in dom_is_node_in_list(), because
dom_sanity_check_node_list_for_insertion() will have already done that.
Closes GH-11914.
This method had some useless logic in it. It checked whether the child
node is a child of its parent, which is always true of course.
But I know where this check comes from, if you follow the spec closely
you'll find that the spec used to have explicit child and parent
arguments for the removal algorithm [1].
That's because that algorithm is written in a generic way, where the
parent and child arguments might not come from the same subtree.
However, in this particular case it *is* always the case that the child
is a child of its parent. The checks weren't needed back then for
DOMChildNode::remove(), and are still not needed today.
[1] e.g. https://web.archive.org/web/20180601092634/https://dom.spec.whatwg.org/#concept-node-remove
According to https://www.php.net/manual/en/class.domdocument:
When using json_encode() on a DOMDocument object the result will be
that of encoding an empty object.
But this was broken in 8.1. The output was `{"config": null}`.
That's because the config property is defined with a default value of
NULL, hence it was included. The other properties are not included
because they don't have a default property, and nothing is ever written
to their backing field. Hence, the JSON encoder excludes them.
Similarly, `(array) $doc` would yield the same `config` key in the
array.
Closes GH-11840.
It looks like the config.w32 uses CHECK_HEADER_ADD_INCLUDE to add the include
path to libxml into the search path.
That doesn't happen in zend-test.
To add to the Windows trouble, libxml is statically linked in, ext/libxml can
only be built statically but ext/zend-test can be built both statically and
dynamically.
So the regression tests won't work in all possible configurations anyway on Windows.
All of this is no problem on Linux because it just uses dynamic linking
and pkg-config, without any magic.
Signed-off-by: Ben Ramsey <ramsey@php.net>
Fixes GHSA-3qrf-m4j2-pcrr.
To parse a document with libxml2, you first need to create a parsing context.
The parsing context contains parsing options (e.g. XML_NOENT to substitute
entities) that the application (in this case PHP) can set.
Unfortunately, libxml2 also supports providing default set options.
For example, if you call xmlSubstituteEntitiesDefault(1) then the XML_NOENT
option will be added to the parsing options every time you create a parsing
context **even if the application never requested XML_NOENT**.
Third party extensions can override these globals, in particular the
substitute entity global. This causes entity substitution to be
unexpectedly active.
Fix it by setting the parsing options to a sane known value.
For API calls that depend on global state we introduce
PHP_LIBXML_SANITIZE_GLOBALS() and PHP_LIBXML_RESTORE_GLOBALS().
For other APIs that work directly with a context we introduce
php_libxml_sanitize_parse_ctxt_options().
At one point this was changed from a bool to an int in libxml2, with
negative values meaning it is unspecified. Because it is cast to a bool
this therefore returned true instead of the expected false.
Closes GH-11793.
* PHP-8.2:
Fix empty argument cases for DOMParentNode methods
Fix DOMCharacterData::replaceWith() with itself
Fix incorrect attribute existence check in DOMElement::setAttributeNodeNS()
Fix DOMEntity field getter bugs
* PHP-8.1:
Fix empty argument cases for DOMParentNode methods
Fix DOMCharacterData::replaceWith() with itself
Fix incorrect attribute existence check in DOMElement::setAttributeNodeNS()
Fix DOMEntity field getter bugs
- publicId could crash PHP if none was provided
- notationName never worked
The fields of this classs were untested. This new test file changes that.
Closes GH-11779.
These checks will always be false because we're dealing with elements
here. DOMElement always are of type XML_ELEMENT_NODE, so they don't need
to be checked.
For typed properties that are of type "string", we don't need to do any
conversion as the zval will already be a string. Removing this
simplifies code and avoids unnecessary refcounting.
