php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #55294 DOMDocument::importNode shifts namespaces when "default" namespace exists
Submitted: 2011-07-27 12:35 UTC Modified: 2024-03-09 16:06 UTC
Votes:6
Avg. Score:4.8 ± 0.4
Reproduced:4 of 4 (100.0%)
Same Version:1 (25.0%)
Same OS:2 (50.0%)
From: hilse at web dot de Assigned: nielsdos (profile)
Status: Closed Package: DOM XML related
PHP Version: trunk-SVN-2011-07-27 (snap) OS: Linux
Private report: No CVE-ID: None
View Developer Edit
 [2011-07-27 12:35 UTC] hilse at web dot de 
Description:
------------
When importing nodes and their children via DOMDocument::importNode, the method 
will introduce the "default" namespace prefix. Herein lies a bug that will trigger 
if the namespace prefix "default" is already assigned (even if not applied to any 
element) within the children of the imported node.

Test script:
---------------
<?php
$aDOM=DOMDocument::loadXML(<<<EOXML
<A xmlns="http://example.hilses.de/A">
	<B>
		<C
			xmlns="http://example.hilses.de/C"
			xmlns:default="http://example.hilses.de/Z" />
	</B>
</A>
EOXML
);

$bDOM=new DOMDocument();
$node = $bDOM->importNode($aDOM->getElementsByTagNameNS('http://example.hilses.de/A','B')->item(0), true);
$bDOM->appendChild($node);

echo $bDOM->saveXML()."\n";
?>

Expected result:
----------------
<?xml version="1.0"?>
<B xmlns="http://example.hilses.de/A" xmlns:default="http://example.hilses.de/C">
		<default:C />
</B>

or even better:

<?xml version="1.0"?>
<B xmlns="http://example.hilses.de/A">
		<C xmlns="http://example.hilses.de/C"/>
</B>

Actual result:
--------------
<?xml version="1.0"?>
<B xmlns="http://example.hilses.de/A" xmlns:default="http://example.hilses.de/C">
	<default:C xmlns="http://example.hilses.de/C" 
xmlns:default="http://example.hilses.de/Z"/>
</B>


(see how C is put into the ".../Z" namespace now instead of ".../C", since 
namespace prefix declarations are valid for the element in which they are 
defined!)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-12-02 19:40 UTC] mike@php.net
-Status: Open +Status: Not a bug
 [2013-12-02 19:40 UTC] mike@php.net 
If, then an upstream bug of libxml2.

xmlNewReconciliedNS() uses "default" as prefix if not already found in the doc.

So either don't use default, or looking at libxml2 sources, default followed by a number in the range 0-1000, or file a bug at http://bugzilla.gnome.org/buglist.cgi?product=libxml2

And on a side note: it happens on append not import.
 [2013-12-03 07:45 UTC] mike@php.net 
Related To: Bug #47530
 [2023-06-15 19:58 UTC] git@php.net 
Automatic comment on behalf of nielsdos
Revision: https://github.com/php/php-src/commit/b30be40b86b62fc681c432fd96840d8e57e172a5
Log: Fix bug #55294 and #47530 and #47847: namespace reconciliation issues
 [2023-06-15 19:58 UTC] git@php.net
-Status: Not a bug +Status: Closed
 [2023-09-28 17:34 UTC] nielsdos@php.net
-Status: Closed +Status: Re-Opened
 [2023-09-28 17:34 UTC] nielsdos@php.net 
Had to revert the fix unfortunately because some applications are dependent on a particular serialization. See https://github.com/php/php-src/pull/12308
I'm planning to work on spec-compliance related issues in the near future (in an opt-in manner), so I will consider this issue as a part of that effort.
 [2023-11-03 22:53 UTC] nielsdos@php.net 
I haven't forgotten about this.
I've contacted the libxml2 maintainer to discuss a solution that does not break BC.
 [2024-03-09 16:06 UTC] nielsdos@php.net
-Status: Re-Opened +Status: Closed -Assigned To: +Assigned To: nielsdos
 [2024-03-09 16:06 UTC] nielsdos@php.net 
The fix for this bug has been committed.
If you are still experiencing this bug, try to check out latest source from https://github.com/php/php-src and re-test.
Thank you for the report, and for helping us make PHP better.

This is fixed in the new opt-in spec-compliance mode, which was merged in https://github.com/php/php-src/pull/13031.
For more information about the opt-in mode, please see https://wiki.php.net/rfc/opt_in_dom_spec_compliance.
In short: the behaviour of the old DOM classes are unaffected for backwards-compatibility reasons. There are new DOM classes where your code is correctly handled.
This feature will be available in PHP 8.4.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Apr 23 09:01:27 2025 UTC