Bug #63380 [Asn]: Allocation via libxml does not use PHP's per-request allocator
Edit report at https://bugs.php.net/bug.php?id=63380&edit=1
ID: 63380
Updated by: rricha...@php.net
Reported by:tstarl...@php.net
Summary:Allocation via libxml does not use PHP's per-request
allocator
Status: Assigned
Type: Bug
Package:XML related
Operating System: Linux
PHP Version:master-Git-2012-10-29 (Git)
-Assigned To:rrichards
+Assigned To:tstarling
Block user comment: N
Private report: N
New Comment:
There is a major problem with doing this and why I didn't end tying into the
PHP
memory allocator. Depending upon setup, it is extremely likely to be able to
hit
memory corruption and/or mix memory allocations between modules. i.e. using
mod_perl and mod_php will cause PHP to override the libxml memory handling
functions (which are global) and bleed into mod_perl (or any others that are
using libxml2) causing any number of results (crashes, security issues, etc..).
The only way to be able to do something like this would be to make it compile
time option which is disabled by default allowing those who know their
environment intimately can utilize this at their own risk, Don't know if you
want to write a patch for that or not. Otherwise I don't see any way this could
safely be added,
Previous Comments:
[2012-10-29 21:55:03] tstarl...@php.net
https://github.com/php/php-src/pull/223
[2012-10-29 03:25:17] tstarl...@php.net
Description:
Allocation via libxml does not use PHP's per-request allocator. So any memory
used by libxml will not be accounted against memory_get_usage() or memory_limit.
At Wikimedia we use libxml DOM trees to store wikitext parse trees, because
they are more compact in memory than the equivalent pure-PHP data structures.
When these parse trees are cached, the memory requirements can become
excessive, and the memory is typically not returned to the system after request
termination. Using xmlMemSetup() to set hook functions which use PHP's
per-request allocation functions will allow us to more effectively monitor and
limit the use of libxml in production.
I've developed a patch and will submit it to GitHub as a pull request.
Test script:
---
$doc = new DOMDocument;
for ( $i = 0; $i < 100 ; $i++ ) {
$doc->appendChild($doc->createElement('foo'));
}
print memory_get_usage()."\n";
Expected result:
312331440 (with debug and ZTS)
Actual result:
--
694256
--
Edit this bug report at https://bugs.php.net/bug.php?id=63380&edit=1
Bug #55279 [Asn->Nab]: SimpleXml removes line breaks
Edit report at https://bugs.php.net/bug.php?id=55279&edit=1
ID: 55279
Updated by: rricha...@php.net
Reported by:mathieu at webberig dot be
Summary:SimpleXml removes line breaks
-Status: Assigned
+Status: Not a bug
Type: Bug
Package:SimpleXML related
Operating System: Windows
PHP Version:5.3.6
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Attribute values are normalized: http://www.w3.org/TR/REC-xml/#AVNormalize
Previous Comments:
[2011-07-25 06:27:06] paj...@php.net
As http://www.w3.org/TR/REC-xml/#NT-AttValue says than new lines are valid in
attribute values, it seems that almost no parser returns them.
This is certainly a problem in libxml itself as simplexml does not transform
the
values returned by libxml.
Assigne to Rob so he can check with the libxml devs, whether we like to change
that or not :)
[2011-07-25 06:17:55] mathieu at webberig dot be
Description:
SimpleXML seems to ignore/remove line breaks (\n) in the attributes. Line
breaks
inside an attribute are valid XML, but they're lost when you use SimpleXML to
read
the XML data.
I encountered this problem when reading XML data provided by the Google
Webmaster
Tools API
Test script:
---
XML:
PHP:
$xml = simplexml_load_string($xmldata);
foreach ($xml->entry as $entry)
{
$attributes = $entry->attributes();
print_r($attributes);
}
Expected result:
Keep the line breaks from the attribute values after reading the string.
$attributes['description'] == "this is the first line
here's a second line
and another!";
Actual result:
--
The string no longer contains line breaks:
$attributes['description'] == "this is the first line here's a second line and
another!";
--
Edit this bug report at https://bugs.php.net/bug.php?id=55279&edit=1
Bug #63015 [Asn->Csd]: Incorrect arginfo for DOMErrorHandler
Edit report at https://bugs.php.net/bug.php?id=63015&edit=1 ID: 63015 Updated by: rricha...@php.net Reported by:Jared dot Williams1 at ntlworld dot com Summary:Incorrect arginfo for DOMErrorHandler -Status: Assigned +Status: Closed Type: Bug Package:DOM XML related Operating System: Irrelevant PHP Version:5.4.6 Assigned To:rrichards Block user comment: N Private report: N New Comment: The fix for this bug has been committed. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-09-20 06:38:45] rricha...@php.net Automatic comment on behalf of rrichards Revision: http://git.php.net/?p=php-src.git;a=commit;h=ffa72707c86750816f665656c02a0a0451300296 Log: fix bug #63015 (Incorrect arginfo for DOMErrorHandler) [2012-09-13 13:34:59] chr...@php.net Have to assign this to Rob, he's much better in this area than me [2012-09-05 14:18:41] larue...@php.net yes,, very likely, assign to the author :), chregu, could you confirm this? thanks [2012-09-05 13:52:29] Jared dot Williams1 at ntlworld dot com Description: Arg info for the DOMErrorHandler contains as class hint for DOMError http://lxr.php.net/xref/PHP_5_4/ext/dom/domerrorhandler.c#30 Which is undefined. I suspect it should mean DOMDomError ? -- Edit this bug report at https://bugs.php.net/bug.php?id=63015&edit=1
Bug #60027 [Opn->Bgs]: DOMDocument::schemaValidate
Edit report at https://bugs.php.net/bug.php?id=60027&edit=1 ID: 60027 Updated by: rricha...@php.net Reported by:richard at organicdata dot co dot za Summary:DOMDocument::schemaValidate -Status: Open +Status: Bogus Type: Bug Package:DOM XML related Operating System: Centos 5.5 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. issue in libxml not PHP Previous Comments: [2011-10-14 09:16:23] richard at organicdata dot co dot za I'm becoming very concerned at the apparent lack of positive interest in this issue from the PHP team. Even the risk of inability to validate one of the world's most used document formats should in my opinion be high on PHPs agenda - and if it indeed is a problem under xmllint then the PHP team should be pushing xmllint to sort it out - as ultimately it is PHP that benefits from the functionality. Just to give you some sense in our case - this functionality is critical and not being able to use it or get it fixed may be enough to stop our use of PHP - which I would be really sad to see happen as it is a great language in many regards. I am more than willing to help in any way I can with samples, testing and so on however I am unable to fix this on my own. I do need someone from the team to engage constructively. If someone could please engage I would really appreciate it. thanks [2011-10-13 06:49:56] richard at organicdata dot co dot za Hello I'm afraid the below isn't clear for me. Please can we keep this simple. All I need is either: 1. to be told how to upload the tiny XML file that has been requested by "cataphract at php.net"; or 2. for Felipe to confirm that he has received the XML file and for him to provide it to the appropriate person; as I have sent it to his email address "felipe at php.net" could someone please help here so this can move forward and hopefully be resolved as soon as possible. thank you [2011-10-11 22:22:17] fel...@php.net The bug tracker just allows the following mime-types: application/x-txt, text/plain, text/x-diff, text/x-patch, text/x-c++, text/x-c, text/x-m4 and cannot be larger than 100k. [2011-10-11 18:54:42] richard at organicdata dot co dot za hi i'm out of ideas - I htmlencoded the example xml file and submitted and I get this message ERROR: Please do not SPAM our bug system. please can someone help me with ideas as to how to submit the xml file requested thanks! [2011-10-11 18:36:23] richard at organicdata dot co dot za ah since I see the last comment immediately I can only assume that the site doesn't handle pasted xml comments. Is there any way I can upload the example file or is there some other preferred method of file submission? thanks again The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60027 -- Edit this bug report at https://bugs.php.net/bug.php?id=60027&edit=1
Req #44761 [Opn->Bgs]: DOM & Large Files
Edit report at https://bugs.php.net/bug.php?id=44761&edit=1 ID: 44761 Updated by: rricha...@php.net Reported by:xwisdom at yahoo dot com Summary:DOM & Large Files -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Windows XP PHP Version:5.2.5 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2011-10-14 15:27:16] clicky at erebot dot net The DOM extension is meant explicitely to handle small XML files as it requires a copy of the file being processed and a large number of objects be kept in memory (this is also true for the SimpleXML extension which is based on the same underlying parsing library). If you need a faster alternative, I'd suggest you take a look at the XMLReader and XML Parser extensions (http://php.net/manual/en/book.xmlreader.php and http://php.net/manual/en/book.xml.php, respectively). XMLReader works by using a cursor-based parsing approach, while XML Parser uses a push-based approach. Here are some drawbacks though when using these extensions: - validation may not be possible (true XML Parser) - you can't use XPath to browse through the data (true for both extensions) Hope this helps. [2008-04-17 14:34:45] xwisdom at yahoo dot com Description: I think the (X)HTML DOM features are great but I would like for it to process the DOMDocument much faster. It appears that the HTML DOM features in php are not able to handle large html files (200k+). It's slow down when processing these files. I would like to request that the DOM processing objects be given a speed boost. The DOM that's present in the browsers are much faster at processing the element. If this can be done then it would be great! -- Edit this bug report at https://bugs.php.net/bug.php?id=44761&edit=1
Bug #55766 [Opn->Bgs]: Incorrect xPath in children nodes
Edit report at https://bugs.php.net/bug.php?id=55766&edit=1
ID: 55766
Updated by: rricha...@php.net
Reported by:ekazakov at parallels dot com
Summary:Incorrect xPath in children nodes
-Status: Open
+Status: Bogus
Type: Bug
Package:SimpleXML related
Operating System: CentOS 5
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Fix your xpath expression not to search entire document
Previous Comments:
[2011-09-23 05:57:19] ekazakov at parallels dot com
Description:
For children nodes SimpleXMLElement::xpath searches the matching xPath in
parent
node.
Workaround:
Create new instances of SimpleXMLElement for each child.
$xmlNode = new SimpleXMLElement($xmlNode->asXML());
Test script:
---
$xmlData = <<
first
second
XML;
$xmlObj = new SimpleXMLElement($xmlData);
foreach ($xmlObj->children() as $xmlNode) {
echo "" . htmlspecialchars($xmlNode->asXML()) . "";
var_dump($xmlNode->xpath("//a"));
}
Expected result:
first
array(1) { [0]=> object(SimpleXMLElement)#333 (1) { [0]=> string(5) "first" } }
second
array(1) { [0]=> object(SimpleXMLElement)#333 (1) { [0]=> string(6) "second" } }
Actual result:
--
first
array(2) { [0]=> object(SimpleXMLElement)#333 (1) { [0]=> string(5) "first" }
[1]=> object(SimpleXMLElement)#335 (1) { [0]=> string(6) "second" } }
second
array(2) { [0]=> object(SimpleXMLElement)#331 (1) { [0]=> string(5) "first" }
[1]=> object(SimpleXMLElement)#333 (1) { [0]=> string(6) "second" } }
--
Edit this bug report at https://bugs.php.net/bug.php?id=55766&edit=1
Req #48587 [Asn->Csd]: MySQL PDO driver doesn't support SSL connections
Edit report at http://bugs.php.net/bug.php?id=48587&edit=1 ID: 48587 Updated by: rricha...@php.net Reported by:michael dot stringer at yuuguu dot com Summary:MySQL PDO driver doesn't support SSL connections -Status: Assigned +Status: Closed Type: Feature/Change Request Package:PDO related Operating System: * PHP Version:* -Assigned To:mysql +Assigned To:rrichards Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-04-15 16:24:42] rricha...@php.net Automatic comment from SVN on behalf of rrichards Revision: http://svn.php.net/viewvc/?view=revision&revision=310239 Log: Implement FR #48587 (MySQL PDO driver doesn't support SSL connections) [2011-02-09 16:04:41] michael dot stringer at yuuguu dot com As of version 5.3.5 this still hasn't been implemented so it is not limited to 5.2.* [2011-02-09 15:51:10] and...@php.net 5.2.* only? If yes, then this will be won't fix. [2010-10-28 09:46:22] u...@php.net 5.2 is closed, http://www.php.net/archive/2010.php#id2010-07-22-1 The PHP development team would like to announce the immediate availability of PHP 5.2.14. This release focuses on improving the stability of the PHP 5.2.x branch with over 60 bug fixes, some of which are security related. This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance. Security fixes for PHP 5.2 might be published on a case by cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3 [2009-06-17 15:55:44] michael dot stringer at yuuguu dot com Description: The mysqli driver supports connecting to MySQL databases using SSL certificates via the ssl_set command (which in turn calls the native client ssl_set function). Please add this functionality to the PDO driver. This is currently preventing us from switching from the mysqli APIs to PDO. -- Edit this bug report at http://bugs.php.net/bug.php?id=48587&edit=1
Bug #54138 [Opn->Bgs]: DOMNode::getLineNo() doesn't return line number higher than 65535
Edit report at http://bugs.php.net/bug.php?id=54138&edit=1 ID: 54138 Updated by: rricha...@php.net Reported by:dmitrij at stepanov dot lv Summary:DOMNode::getLineNo() doesn't return line number higher than 65535 -Status: Open +Status: Bogus Type: Bug Package:XML Reader Operating System: Windows 7 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Known limitation of libxml2 Previous Comments: [2011-03-02 15:23:44] dmitrij at stepanov dot lv Description: DOMNode::getLineNo() doesn't return line number higher than 65535. I assume that unsigned short is used for file line enumeration either in XMLReader or DOMNode internals. Test script: --- Try reading with XMLReader an XML file that has more than 65535 lines. Then, when line nr. > 65535 is reached, call XMLReader::expand()->getLineNo(). Expected result: Correct line number. Actual result: -- 65535 for lines, higher than 65525. -- Edit this bug report at http://bugs.php.net/bug.php?id=54138&edit=1
Bug #54120 [Opn->Bgs]: Impossible to freed memory complety after call to Xpath() method.
Edit report at http://bugs.php.net/bug.php?id=54120&edit=1
ID: 54120
Updated by: rricha...@php.net
Reported by:ikaos at gmx dot fr
Summary:Impossible to freed memory complety after call to
Xpath() method.
-Status: Open
+Status: Bogus
Type: Bug
Package:SimpleXML related
Operating System: Linux CentOS 5.5 x86_64
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Memory is freed. http://xmlsoft.org/xmlmem.html you can read how memory
is managed
and might not be returned immediately to the kernel.
Previous Comments:
[2011-02-28 15:58:00] ikaos at gmx dot fr
Description:
---
>From manual page: http://www.php.net/simplexmlelement.xpath
---
Test script:
---
xpath('/ITEMS/ITEM');
$sxe = NULL; $nodes = NULL;
print("Memory after freed memory : " . memory_get_usage() . PHP_EOL .
PHP_EOL);
// short sleep, time to launch 'ps aux'
sleep(10);
?>
Expected result:
When I unset (or set to NULL) the result of the Xpath() method ($nodes
in the example), I expect memory will be completly freed. It's not the
case.
I tried, to recursively unset each element from $nodes and I got the
same result.
Actual result:
--
Result of the test script :
Without call to xpath method :
Memory before SXE : 625736
Memory after freed memory : 625904
Calling xpath method :
Memory before SXE : 625904
Memory after freed memory : 1608944
memory_get_usage says that few kilos octets of memory are still used,
but in reality several thousand mega octets are still used.
# ps aux | grep test.php
me 28859 83.4 48.3 *1119908* *996056* pts/3 S+ 15:30 0:08 /bin/php
test.php
--
Edit this bug report at http://bugs.php.net/bug.php?id=54120&edit=1
Req #50973 [Asn->Dup]: DOMDocument::saveHTML() should be able to take a node as an arg
Edit report at http://bugs.php.net/bug.php?id=50973&edit=1 ID: 50973 Updated by: rricha...@php.net Reported by:geoffers+phpbugs at gmail dot com Summary:DOMDocument::saveHTML() should be able to take a node as an arg -Status: Assigned +Status: Duplicate Type: Feature/Change Request Package:DOM XML related Operating System: * PHP Version:5.*, 6 Assigned To:rrichards Block user comment: N Private report: N New Comment: dupe of bug #39771 which was already taken care of Previous Comments: [2010-11-28 11:58:09] valid at example dot com When this gets fixed, it should also fix http://bugs.php.net/bug.php?id=39771 [2010-03-05 22:06:34] paj...@php.net Rob, what's your opinion on this patch? [2010-02-10 18:25:44] geoffers+phpbugs at gmail dot com http://pastebin.ca/1792855 is a patch for this, based upon saveXML(). There is one notable difference between what I have, based on that, and what is currently there: the if (mem) within the if (!size) is not present within saveXML(), and nor as a result in my patch. I presume that it should either be in both saveXML and saveHTML or neither: any idea? And, of course, my prior comment was wrong: it's only saveXML() which has the argument, not save(). [2010-02-09 16:00:06] geoffers+phpbugs at gmail dot com Description: At the moment DOMDocument::save() and DOMDocument::saveXML() both take an optional first argument which is a node to serialize; DOMDocument::saveHTML() and DOMDocument::saveHTMLFile() have no such option and always serialize the whole file. For cases where HTML serialization is needed of a specific node, all that can be done is doing it within PHP code (which is comparatively very slow). As libxml includes the needed APIs to do this, it doesn't appear to be overly complex to implement. I'll try to write a patch for this later. -- Edit this bug report at http://bugs.php.net/bug.php?id=50973&edit=1
Bug #53726 [Opn->Fbk]: importnode (deep) -> nodes named as "link"
Edit report at http://bugs.php.net/bug.php?id=53726&edit=1
ID: 53726
Updated by: rricha...@php.net
Reported by:somiara at hotmail dot com
Summary:importnode (deep) -> nodes named as "link"
-Status: Open
+Status: Feedback
Type: Bug
Package:DOM XML related
Operating System: Windows NT 6.1 build 7
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
The example script while works fine for me is not the same as what you
have for
output nor what you expect. Can you provide a complete script with the
actual
output you are getting and where the error is?
Previous Comments:
[2011-01-12 16:49:28] somiara at hotmail dot com
Description:
import of nodes named as "link" kills trailing-slashs/-tags?
Test script:
---
$xml = new DOMDocument;
$xml_dir = $xml->createElement("item");
$pagedoc = new DOMDocument;
$pagedoc->load($broadcaster.'test.xml');
$xml_page = $xml->createElement("page");
$xml_page = $xml->importNode($pagedoc->documentElement, true);
$xml_dir->appendChild($xml_page);
$xml->appendChild($xml_dir);
## file 1
def
file 2
def
Expected result:
## -> file 1
def
## -> file 2
def
Actual result:
--
## -> file 1
def
## -> file 2
--
Edit this bug report at http://bugs.php.net/bug.php?id=53726&edit=1
Bug #52640 [Opn->Bgs]: Odd Garbage collection Behaviour with Dom Node
Edit report at http://bugs.php.net/bug.php?id=52640&edit=1
ID: 52640
Updated by: rricha...@php.net
Reported by:ken at smallboxcms dot com
Summary:Odd Garbage collection Behaviour with Dom Node
-Status: Open
+Status: Bogus
Type: Bug
Package:DOM XML related
Operating System: Linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
DOM objects are just wrappers to underlying libxml2 structures and
unless directly
referenced, i.e. $blah->node = $node, the $node object is no longer
referenced
outside of the function. Appending the node appends the libxml2 node
structure to
the underlying xml tree, does nothing in respect to the DOM object
wrapper.
Previous Comments:
[2010-08-19 00:32:30] ken at smallboxcms dot com
Description:
Variables added to dom nodes are later unset. This behaviour does not
appear to happen with other types of PHP objects.
Test script:
---
doc = $doc;
$node = $doc->createElement('node');
$doc->appendChild($node);
$node->foo = true;
$obj = new stdClass;
$blah->obj = $obj;
$obj->child = new stdClass;
$obj->child->foo = true;
}
humbug();
echo "Should be set: ".$blah->doc->firstChild->foo."\n";
echo "Is Set: ".$blah->obj->child->foo."\n";
?>
Expected result:
I would expect that $blah->doc->firstChild->foo would be set after the
function call.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52640&edit=1
Bug #53569 [Opn->Bgs]: Intermittent Seg Fault during DOMDocument clean up
Edit report at http://bugs.php.net/bug.php?id=53569&edit=1
ID: 53569
Updated by: rricha...@php.net
Reported by:chris dot richard at gmail dot com
Summary:Intermittent Seg Fault during DOMDocument clean up
-Status: Open
+Status: Bogus
Type: Bug
Package:DOM XML related
Operating System: Linux (Ubuntu 10)
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
This is a bug in libxml2 which will be fixed in its 2.7.9 release.
Unfortunately
there is no simple workaround that can be done in the DOM extension for
this
without adding significant overhead just for this specific case.
Previous Comments:
[2010-12-20 17:30:24] chris dot richard at gmail dot com
This script reproduces the issue fairly consistently on my machine:
loadXML(
"".
'http://www.w3.org/TR/html4/strict.dtd"; [
]>'.
"");
$fragment = $doc->createDocumentFragment();
$fragment->appendXML("");
$doc->documentElement->appendChild($fragment);
ob_start();
?>
lorem ipsum dolor sit amet lorem ipsum dolor sit amet lorem ipsum
dolor sit
amet
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
When the mortgage rate is 'fixed' it means that the rate (%) is set
for the
duration of the term, whereas with a variable mortgage rate, the rate
fluctuates
with the market interest rate, known as the 'prime rate'. So, for
example, if
the 5 year fixed mortgage rate is 4%, then you will pay 4% interest
throughout
the term of the mortgage.
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
Popularity of the 5-year fixed rate
Mortgages by length of term and age group
Age group
18-34 35-54 55+ All
ages
1 year term
5%
7%
6%
6%
2-4 year term
27%
18%
12%
20%
5 year term
66%
65%
69%
66%
6-10 year term
3%
9%
10%
7%
>10 year term
0
0
2%
1%
createDocumentFragment();
$fragment->appendXML($output);
$xpath = new DOMXpath($doc);
$insert = $xpath->query(".//insert")->item(0);
$insert->parentNode->replaceChild($fragment, $insert);
echo $doc->saveHTML();
?>
[2010-12-18 16:57:51] cataphr...@php.net
Can you provide a small script that reproduces this issue?
It's complicated to find the error from backtraces that happen in the
destruction phase; by this time the harm has long been done.
Also please use the latest version of PHP.
Thank you.
[2010-12-18 06:16:59] chris dot richard at gmail dot com
PHP 5.3.2
libxml 2.7.6
[2010-12-18 06:11:31] chris dot richard at gmail dot com
Description:
libxml causes a seg fault *intermittently* after all PHP user code has
finished
running.
I'm using DOMFragment to parse chunks of XHTML and append them to a
DOMDocument
which gets output (via saveHTML) once it's completely assembled. The
output
completes successfully but at least half the time I get seg fault
related to the
clean up of the DOMDocument and no response is sent to the client.
Core Dump:
#0 0x7fb2f77c6e6f in xmlDictOwns () from /usr/lib/libxml2.so.2
#1 0x7fb2f77276a7 in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#2 0x7fb2f76ff85f in ?? () from /usr/lib/libxml2.so.2
#3 0x7fb2f772f256 in xmlHashFree () from /usr/lib/libxml2.so.2
#4 0x7fb2f7727335 in xmlFreeDtd () from /usr/lib/libxml2.so.2
#5 0x7fb2f772746a in xmlFreeDoc () from /usr/lib/libxml2.so.2
#6 0x7fb2f8409d5b in php_libxml_decrement_doc_ref ()
from /usr/lib/apache2/modules/libphp5.so
#7 0x7fb2f842e8cf in ?? () from
/usr/lib/apache2/modules/libphp5.so
#8 0x7fb2f8661adc in zend_objects_store_del_ref_by_handle_ex ()
from /usr/lib/apache2/modules/libphp5.so
#9 0x7fb2f8661b03 in zend_objects_store_del_ref ()
from /usr/lib/apache2/modules/libphp5.so
#10 0x7fb2f86301cd in _zval_ptr_dtor () from
/usr/lib/apache2/modules/libphp5.so
#11 0x7fb2f8649198 in zend_hash_destroy () from
/usr/lib/apache2/modules/libphp5.so
#12 0x7fb2f863c19f in _zval_dtor_func () from
/usr/lib/apache2/modules/libphp5.so
#13 0x7fb2f86301cd in _zval_ptr_dtor () from
Req #53950 [Opn]: Add a way to configure where libxml searches for Catalog Files
Edit report at http://bugs.php.net/bug.php?id=53950&edit=1 ID: 53950 Updated by: rricha...@php.net Reported by:gordon at onlinehome dot de Summary:Add a way to configure where libxml searches for Catalog Files Status: Open Type: Feature/Change Request Package:*XML functions Operating System: any PHP Version:Irrelevant -Assigned To: +Assigned To:rrichards Block user comment: N Private report: N New Comment: Assign to self as I asked him to open this Previous Comments: [2011-02-08 19:18:43] cataphr...@php.net > This, by itself, makes it inviable to write a PHP function that allows > replacing the default catalog unless some (probably expensive, since a > catalog file must be read) on request startup/shutdown is used. The unless part doesn't actually make sense in the multi-threading versions of PHP. [2011-02-08 19:14:49] cataphr...@php.net I know very little of libxml2, but as far as I infer from http://xmlsoft.org/catalog.html and from the code in catalog.c, there is no way to specify a global catalog in a thread-local manner. This, by itself, makes it inviable to write a PHP function that allows replacing the default catalog unless some (probably expensive, since a catalog file must be read) on request startup/shutdown is used. libxml2 supports per-document catalogs, but from what I see, your document must contain an oasis-xml-catalog processing instruction, like this: http://example.com/catalog.xml";?> http://www.example.com/schema/doc.dtd";> There is another alternative, which is using an external entity loader (see http://xmlsoft.org/html/libxml-parser.html#xmlSetExternalEntityLoader ), but this is less convenient, though probably we could also expose some functions to deal with catalogs for use in the user-supplied callback. I could implement this, but I'm hopping someone else with more libxml2 knowledge could tell if my analysis is correct. [2011-02-07 17:16:37] gordon at onlinehome dot de Description: Libxml can use catalog files to provide a local cache mechanism allowing to load the entities associated to public identifiers or remote resources. There is currently no way to configure the catalog file path from PHP. Configuring the path in libxml itself seems possible: > The user can change the default catalog behaviour by redirecting queries to its own set of catalogs. This can be done by setting the XML_CATALOG_FILES environment variable to a list of catalogs, an empty one should deactivate loading the default /etc/xml/catalog default catalog. It would be nice if PHP's libxml extension would provide a way to set the path somehow. This could be helpful when validating documents with remote System Identifiers, like any HTML DTD. Or simply to bundle files with an application. Related Resources: - http://xmlsoft.org/catalog.html - http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic - http://bugs.php.net/48080 - http://bugs.php.net/32426 -- Edit this bug report at http://bugs.php.net/bug.php?id=53950&edit=1
Bug #52450 [Opn->Bgs]: $DomDocumentObj->encoding should not affect xml declaration
Edit report at http://bugs.php.net/bug.php?id=52450&edit=1
ID: 52450
Updated by: rricha...@php.net
Reported by:giorgio dot liscio at email dot it
Summary:$DomDocumentObj->encoding should not affect xml
declaration
-Status: Open
+Status: Bogus
Type: Bug
Package:DOM XML related
Operating System: all
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
RTM
Previous Comments:
[2010-09-05 10:13:11] giorgio dot liscio at email dot it
hi, can you examine my request?
thank you
[2010-07-26 23:58:02] giorgio dot liscio at email dot it
Description:
hi
consider this code:
i want to set utf-16 as internal encoding for domdocument
because source data is utf-16 encoded
$doc->encoding = "UTF-16";
but my output for web is handled by:
iconv_set_encoding("internal_encoding", "UTF-16");
iconv_set_encoding("output_encoding", "UTF-8//TRANSLIT//IGNORE");
or can be handled by
echo iconv("UTF-16", "UTF-8", $xmldata);
so the output is utf-8 encoded but the xml declaration says:
so $document->encoding property should work as how it works now, but it
should not affect the xml declaration
in plus you should provide an alternative to set $xmlEncoding (make it
non-readonly)
i'm sorry for my english... i hope you accept this request!
thank you
--
Edit this bug report at http://bugs.php.net/bug.php?id=52450&edit=1
Req #30111 [Opn->Wfx]: Move some DOMDocument properties to static
Edit report at http://bugs.php.net/bug.php?id=30111&edit=1 ID: 30111 Updated by: rricha...@php.net Reported by:phoeniks2k at mail dot ru Summary:Move some DOMDocument properties to static -Status: Open +Status: Wont fix Type: Feature/Change Request Package:DOM XML related Operating System: All PHP Version:5.0.1 Block user comment: N Private report: N New Comment: These are all per document settings and wont change to global. For consistent settings you are better off setting default settings to a var and always passing it to the $options parameter of the load method. Previous Comments: [2004-09-16 13:35:41] phoeniks2k at mail dot ru Description: It's likely to move # validateOnParse- default FALSE (will load and validate against DTD) resolveExternals - default FALSE (will load the DTD without performaing validation) preserveWhiteSpace - default TRUE substituteEntities - default FALSE # properties to statics It's good idea to define theese vars once for all exec time of the script -- Edit this bug report at http://bugs.php.net/bug.php?id=30111&edit=1
Bug #53044 [Opn->Bgs]: Invalid Nodetype to import
Edit report at http://bugs.php.net/bug.php?id=53044&edit=1
ID: 53044
Updated by: rricha...@php.net
Reported by:bbarnetm at yahoo dot com
Summary:Invalid Nodetype to import
-Status: Open
+Status: Bogus
Type: Bug
Package:DOM XML related
Operating System: W2K3
PHP Version:5.2.14
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2010-10-12 06:55:14] bbarnetm at yahoo dot com
I modified my script following your tip I founded enough information for
incluye
aditional lines:
$xmlestilos=ereg_replace("[\\Ã]+","",($xmlestilos));
$xmlestilos=ereg_replace("[\\ð]+","",($xmlestilos));
The script was modified:
if (!($dom->loadXML($xmlestilos))){
$errors = libxml_get_errors();
foreach ($errors as $error) {
echo display_xml_error($error, $xmlestilos);
}
libxml_clear_errors();
}
Thank very much for your tip.
Let me know if in a future versions you will increment the power of xml
functions?
[2010-10-12 05:55:34] cataphr...@php.net
I'd guess the DOMDocument object is empty because the call to loadXML()
failed.
You should do
if (!$dom->loadXML(...)) {
//error loading XML. Call libxml_get_errors() to get details
}
not
if (!$dom) {
Please confirm this is the case.
In any case, the error message could be better...
[2010-10-11 21:22:24] bbarnetm at yahoo dot com
function acentos($valor){
//Le elimina los acentos al string recibido
$registro=$valor;
$registro=ereg_replace("á","a",($registro));
$registro=ereg_replace("é","e",($registro));
$registro=ereg_replace("Ã","i",($registro));
$registro=ereg_replace("ó","o",($registro));
$registro=ereg_replace("ú","u",($registro));
$registro=ereg_replace("Ã","A",($registro));
$registro=ereg_replace("Ã","E",($registro));
$registro=ereg_replace("Ã","I",($registro));
$registro=ereg_replace("Ã","O",($registro));
$registro=ereg_replace("Ã","U",($registro));
$registro=ereg_replace("ñ","n",($registro));
$registro=ereg_replace("Ã","N",($registro));
return $registro;
}
[2010-10-11 21:14:18] bbarnetm at yahoo dot com
Description:
While I'm trying to import an extensive xml, I'm recieving the same
error while I
try to transale to simple xml.
Test script:
---
libxml_use_internal_errors(true);
$xmlestilos=ereg_replace(chr(160),"",(trim($reg[0])));
$xmlestilos=ereg_replace('"',"",$xmlestilos);
$xmlestilos=ereg_replace(",",".",$xmlestilos);
$xmlestilos=ereg_replace("&","",$xmlestilos);
$xmlestilos=ereg_replace(">","",$xmlestilos);
$xmlestilos=ereg_replace("}","",$xmlestilos);
$xmlestilos=ereg_replace("#","",$xmlestilos);
$xmlestilos=ereg_replace("`","",$xmlestilos);
$xmlestilos=ereg_replace(";","",$xmlestilos);
$xmlestilos=ereg_replace("[\\|]+","",$xmlestilos);
$xmlestilos=ereg_replace("[\\]+","/",$xmlestilos);
$xmlestilos=ereg_replace("¦","",($xmlestilos));
$xmlestilos=ereg_replace("º","",($xmlestilos));
$xmlestilos=ereg_replace("´","",($xmlestilos));
$xmlestilos=ereg_replace("¨","",($xmlestilos));
$xmlestilos=ereg_replace("[\\?]+","",($xmlestilos));
$xmlestilos=ereg_replace("[\\¿]+","",($xmlestilos));
$xmlestilos=acentos($xmlestilos);
$xmlestilos=stripslashes($xmlestilos);
$xmlestilos=utf8_decode($xmlestilos);
$dom = new domDocument;
$dom->loadXML($xmlestilos);
if (!$dom) {
//Escribe la respuesta en un archivo
$formato1 = '%d%m%Y'; $hoyes = strftime($formato1);
$archivolog="estilos_".$hoyes.".log";
if (file_exists($archivolog)){unlink($archivolog);}
$fp = fopen ($archivolog, "a");
//fwrite ($fp, trim($reg[0]). PHP_EOL);
fwrite ($fp, trim($xmlestilos). PHP_EOL);
fclose($fp);
print 'MSG-18: SE DETECTO UNA RESPUESTA INVALIDA DEL INS'; die();
}
$xml = simplexml_import_dom($dom);
Expected result:
The xml imported in a simple xml object
Actual result:
--
Warning: simplexml_import_dom() [function.simplexml-import-do
Bug #53393 [Opn->Bgs]: XPath path issue with namespaced elements created with DOMDocument
Edit report at http://bugs.php.net/bug.php?id=53393&edit=1
ID: 53393
Updated by: rricha...@php.net
Reported by:paul dot visco at roswellpark dot org
Summary:XPath path issue with namespaced elements created
with DOMDocument
-Status: Open
+Status: Bogus
Type: Bug
Package:DOM XML related
Operating System: CENTOS 5.5/Fedora 14
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
must use dom level 2 namespace aware methods
Previous Comments:
[2010-11-24 04:01:43] paul dot visco at roswellpark dot org
Description:
When creating a namespaced DOMDocument programmatically (appendChild,
etc), I cannot get DOMXPath to return the same results on the same
underlying XML document as I can when use DOMDocument->loadXML() to
populate the documents XML.
I compiled and tested the latest PHP 5.3.4RC2-dev (cli) (built: Nov 23
2010 21:51:46) using --with-dom and --with-xml and used the latest
stable libxml2-devel.x86_64 2.7.7-2.fc14 from fedora 14 and the problem
still persists.
Sorry its like 25 lines of code with comments, I don't have somewhere
else to put them.
Test script:
---
//Constructing the DOMDocument from XML string allows DOMXPath to work
$xml = <<
http://www.w3.org/2005/Atom";
xmlns:other="http://other.w3.org/other";>uYG7-sPwjFg2009-05-17T18:29:31.000Z
EOT;
$doc = new DOMDocument;
$doc->loadXML($xml);
$xpath = new DOMXPath($doc);
$xpath->registerNamespace('atom', "http://www.w3.org/2005/Atom";);
$entries = $xpath->evaluate('//atom:entry/atom:published/text()');
///prints 2009-05-17T18:29:31.000Z as expected
print $entries->item(0)->nodeValue ;
//Constructing the same exact document programmatically causes DOMXPath
to not work
$doc = new DOMDocument("1.0", "UTF-8");
$entry = $doc->createElement('entry');
$doc->appendChild($entry);
$entry->setAttribute('xmlns', "http://www.w3.org/2005/Atom";);
$entry->setAttribute('xmlns:other', "http://other.w3.org/other";);
$id = $entry->appendChild($doc->createElement('id'));;
$id->appendChild($doc->createTextNode("uYG7-sPwjFg"));
$published = $entry->appendChild($doc->createElement('published'));
$published->appendChild($doc->createTextNode("2009-05-17T18:29:31.000Z"));
$xpath = new DOMXPath($doc);
$xpath->registerNamespace('atom', "http://www.w3.org/2005/Atom";);
$entries = $xpath->evaluate('//atom:entry/atom:published/text()');
//throws error as node is not found
print $entries->item(0)->nodeValue;
Expected result:
I would expect both of the above examples to print
2009-05-17T18:29:31.000Z
Actual result:
--
Example one prints 2009-05-17T18:29:31.000Z and example 2 fails because
the node is not found by Xpath
--
Edit this bug report at http://bugs.php.net/bug.php?id=53393&edit=1
Req #23313 [Opn->Wfx]: Missing DomNode->get_namespace()
Edit report at http://bugs.php.net/bug.php?id=23313&edit=1 ID: 23313 Updated by: rricha...@php.net Reported by:markus dot pfefferle at web dot de Summary:Missing DomNode->get_namespace() -Status: Open +Status: Wont fix Type: Feature/Change Request Package:DOM XML related Operating System: * PHP Version:* Block user comment: N Private report: N New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2003-04-23 06:56:03] markus dot pfefferle at web dot de It's nice that you can create nodes with namespaces, using DomDocument->create_element_ns() and DomNode->add_namespaces(), but for actually reading them, there is no counterpart method (other than prefix(), which is not very safe). My specific problem is that I want to clone a node without its child nodes, but can't use DomNode->clone_node(false), since this does not copy any namespace declarations and attributes either. Adding a DomNode->get_namespace() in future versions would be greatly appreciated. -- Edit this bug report at http://bugs.php.net/bug.php?id=23313&edit=1
Bug #53694 [Opn->Bgs]: SimpleXMLElement does not read XML declaration line.
Edit report at http://bugs.php.net/bug.php?id=53694&edit=1
ID: 53694
Updated by: rricha...@php.net
Reported by:jamone_95134 at yahoo dot com
Summary:SimpleXMLElement does not read XML declaration line.
-Status: Open
+Status: Bogus
Type: Bug
Package:SimpleXML related
Operating System: Windows XP
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
invalid characters before start of declaration.
Previous Comments:
[2011-01-08 10:04:15] jamone_95134 at yahoo dot com
Description:
---
>From manual page: http://www.php.net/simplexml.examples-basic
---
When I run the first example I get the following errors:
$ php test1.php
Warning: SimpleXMLElement::__construct(): Entity: line 1: parser error :
XML
declaration allowed only at the start of th
e document in D:\php_src\XML\test1.php on line 4
Warning: SimpleXMLElement::__construct():in D:\php_src\XML\test1.php on li
ne 4
Warning: SimpleXMLElement::__construct():^ in
D:\php_src\XML\test1.php on line 4
Fatal error: Uncaught exception 'Exception' with message 'String could
not be
parsed as XML' in D:\php_src\XML\test1.php
:4
Stack trace:
#0 D:\php_src\XML\test1.php(4): SimpleXMLElement->__construct('? line from the
example.php
file it runs ok.
So how do we handle the declaration line for xml files with
SimpleXMLElement?
Test script:
---
Just running example 2 from
http://www.php.net/manual/en/simplexml.examples-basic.php
Expected result:
Expected result:
So, this language. It's like, a programming language. Or is it a
scripting language? All is revealed in this thrilling horror spoof
of a documentary.
Actual result:
--
$ php test1.php
Warning: SimpleXMLElement::__construct(): Entity: line 1: parser error :
XML
declaration allowed only at the start of th
e document in D:\php_src\XML\test1.php on line 4
Warning: SimpleXMLElement::__construct():in D:\php_src\XML\test1.php on li
ne 4
Warning: SimpleXMLElement::__construct():^ in
D:\php_src\XML\test1.php on line 4
Fatal error: Uncaught exception 'Exception' with message 'String could
not be
parsed as XML' in D:\php_src\XML\test1.php
:4
Stack trace:
#0 D:\php_src\XML\test1.php(4): SimpleXMLElement->__construct('?http://bugs.php.net/bug.php?id=53694&edit=1
Bug #53677 [Csd->Bgs]: xml_parse_into_struct deletes unescaped character data
Edit report at http://bugs.php.net/bug.php?id=53677&edit=1 ID: 53677 Updated by: rricha...@php.net Reported by:lwc at mailmetrash dot com Summary:xml_parse_into_struct deletes unescaped character data -Status: Closed +Status: Bogus Type: Bug Package:XML related Operating System: Redhat Linux PHP Version:5.2.14 Block user comment: N Private report: N New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. dupe of bug #45996 Previous Comments: [2011-01-07 01:25:26] lwc at mailmetrash dot com Sorry, you can delete this bug. The fixed description made me realize it's a duplicate of #45996. [2011-01-06 22:05:23] lwc at mailmetrash dot com Sorry, here's a fixed description.tag should turn into: [name] => this [value] => tag But in some cases it turns into: [name] => this [value] => tag/ That is, it's not even kept. It's just deleted! [2011-01-06 21:48:10] lwc at mailmetrash dot com As for the "(as claimed in)" comment, you can delete it. They actually claim you should use straight up HTML without escaping it. Problem is the parser then treats the HTML tags like XML ones. If you have a solution for that one, please post it there. [2011-01-06 21:40:58] lwc at mailmetrash dot com Description: Assuming #26528 is also valid for the actual character data (as claimed in http://forum.alicebot.org/viewtopic.php?t=69), then the parser should decode into: [name] => this [value] => The problem is in some cases it stays as: [name] => this [value] => In my 2 unrelated servers, the decoding works in v5.2.6 but fails in v5.2.14. Please check in newer versions, if you can! -- Edit this bug report at http://bugs.php.net/bug.php?id=53677&edit=1
Req #53655 [Opn->Asn]: Improve speed of DOMNode::C14N() on large XML documents
Edit report at http://bugs.php.net/bug.php?id=53655&edit=1
ID: 53655
Updated by: rricha...@php.net
Reported by:olav dot morken at uninett dot no
Summary:Improve speed of DOMNode::C14N() on large XML
documents
-Status: Open
+Status: Assigned
Type: Feature/Change Request
Package:DOM XML related
PHP Version:5.3.4
-Assigned To:
+Assigned To:rrichards
Block user comment: N
Private report: N
Previous Comments:
[2011-01-05 08:33:02] olav dot morken at uninett dot no
Description:
The C14N() function appears to have a runtime that is O(N^2) (or
possibly worse?) depending on input size, which means that it becomes
very slow as the input grows. For example, an input with around 196000
nodes takes about 290 seconds, while an input with 486000 nodes takes
2200 seconds.
Note that this problem only occurs when canonicalizing a subtree of the
docuemnt. If we canonicalize the whole document, it completes almost
immediately.
The problem is that canonicalization uses an XPath expression to find
the nodeset that should be canonicalized. Evaluation of the XPath
expression takes a lot of time as the input size grows, but the libxml2
xmlC14NDocSaveTo() function also has to do a lookup in the nodeset
returned by the XPath expression for every node it encounters.
I believe a better solution would be to do this like it is done in the
xmlsec library. This library use the xmlC14NExecute()-function instead,
which accepts a callback that determines whether a node should be
included in the result. This should make the speed of canonicalization
linear with the input size.
Test script:
---
load('some-large-xml-file.xml');
$start = microtime(TRUE);
$doc->documentElement->C14N(FALSE, FALSE);
echo "Done in " . (microtime(TRUE) - $start) . " seconds.\n";
--
Edit this bug report at http://bugs.php.net/bug.php?id=53655&edit=1
Bug #45996 [Csd]: libxml2 2.7.1 causes breakage with character data in xml_parse()
Edit report at http://bugs.php.net/bug.php?id=45996&edit=1 ID: 45996 Updated by: rricha...@php.net Reported by:phpbugs at colin dot guthr dot ie Summary:libxml2 2.7.1 causes breakage with character data in xml_parse() Status: Closed Type: Bug Package:XML related Operating System: Mandriva Linux PHP Version:5.2.6 Assigned To:rrichards Block user comment: N Private report: N New Comment: HTML is not XML so non issue as the sax parser is not meant to handle HTML If PHP is not linked against 2.7.3 or higher it wont work either. So back to "Compile PHP (5.2.9 or higher) against the newer libxml (2.7.3 or higher)" as most of those search results even tell you. Without phpinfo and your sample code I would say the problem is on your end Previous Comments: [2011-01-04 21:54:53] lwc at mailmetrash dot cm Regarding your e-mail message, please let's continue this discussion publicly. It's established that this bug can happen with any (HTML) input, so there's no point exposing my own. Check out http://www.google.com/search?q=libxml+%2Bbrackets for tons of example code. But most importantly, is it possible that all this time no one ever posted a bug about it in libxml's own tracker? If so, I think I'll post something there soon. [2011-01-04 20:55:54] lwc at mailmetrash dot com Again, I use libxml v2.7.7 (with PHP v5.2.14). [2011-01-04 20:04:33] rricha...@php.net To hopefully close this once and for all: Compile PHP (5.2.9 or higher) against the newer libxml (2.7.3 or higher). PHP code change: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/ext/xml/compat.c? r1=272374&r2=273286 Libxml code change: http://svn.gnome.org/viewvc/libxml2/trunk/parser.c?r1=3803&r2=3807 [2011-01-04 19:50:35] lwc at mailmetrash dot com It still happens to me even in libxml v2.7.7. Please take it seriously. At least mention in what scenarios does it happen and does it have a link in libxml's own bug tracker. [2010-07-07 23:17:53] i_cypher at hotmail dot com I am seeing this error in 2.7.3 as well, so the fix does not seem to be working. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=45996 -- Edit this bug report at http://bugs.php.net/bug.php?id=45996&edit=1
Bug #45996 [Csd]: libxml2 2.7.1 causes breakage with character data in xml_parse()
Edit report at http://bugs.php.net/bug.php?id=45996&edit=1 ID: 45996 Updated by: rricha...@php.net Reported by:phpbugs at colin dot guthr dot ie Summary:libxml2 2.7.1 causes breakage with character data in xml_parse() Status: Closed Type: Bug Package:XML related Operating System: Mandriva Linux PHP Version:5.2.6 Assigned To:rrichards Block user comment: N Private report: N New Comment: To hopefully close this once and for all: Compile PHP (5.2.9 or higher) against the newer libxml (2.7.3 or higher). PHP code change: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/ext/xml/compat.c? r1=272374&r2=273286 Libxml code change: http://svn.gnome.org/viewvc/libxml2/trunk/parser.c?r1=3803&r2=3807 Previous Comments: [2011-01-04 19:50:35] lwc at mailmetrash dot com It still happens to me even in libxml v2.7.7. Please take it seriously. At least mention in what scenarios does it happen and does it have a link in libxml's own bug tracker. [2010-07-07 23:17:53] i_cypher at hotmail dot com I am seeing this error in 2.7.3 as well, so the fix does not seem to be working. [2010-04-19 00:05:30] nick dot phillips at otago dot ac dot nz Just FYI - I have been seeing what would appear to be this issue with libxml2 2.7.6 (with Moodle), so it seems that "2.7.3 or higher" doesn't cut it. Reverting to 2.6.32 solved the problem for me. [2009-01-11 12:06:01] rricha...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. This fix also requires the soon to be released libxml2-2.7.3 or higher when using 2.7.x. [2009-01-03 04:03:53] david+phpbugs at midrange dot com Ok, I'm going to try and rebuild the Fedora 8 source RPM to avoid the libxml2 bug ... but I'm not all that familiar with how PHP is built ... and could use a pointer or two on what to change on the configure command line. Any suggestions? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=45996 -- Edit this bug report at http://bugs.php.net/bug.php?id=45996&edit=1
Bug #53628 [Opn->Bgs]: Lack of support for character references
Edit report at http://bugs.php.net/bug.php?id=53628&edit=1
ID: 53628
Updated by: rricha...@php.net
Reported by:alexander dot grimalovsky at gmail dot com
Summary:Lack of support for character references
-Status: Open
+Status: Bogus
Type: Bug
Package:DOM XML related
Operating System: All
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
createEntityReference works per spec. It is only supposed to support
entity
references - not character references. You typically use a text node
with escaped
data to add characters.
Previous Comments:
[2010-12-29 17:58:21] alexander dot grimalovsky at gmail dot com
Description:
DOM extension for PHP supports XML entity references by implementing
DOMEntityReference class. However due to incorrect entity name
validation this class only allows working with named entity references,
not character references.
libxml2, which is used as backend implementation for DOM XML operations
have 2 functions for creating entity references:
xmlNewReference() - for entity references, it is used by DOM extension
xmlNewCharRef() - for character references, it is not used by DOM
extension and hence causes extension to lack support for this kind of
entities.
Moreover, implementation of DOMEntityReference::__construct() in
ext/dom/entityreference.c uses libxml2 function xmlValidateName() for
validating entity name which checks for Name (see
http://www.w3.org/TR/REC-xml/#NT-EntityRef). Of course this check is
failed on character references ( see
http://www.w3.org/TR/REC-xml/#NT-CharRef) and hence causes exception or
warning error to be thrown.
Correct implementation should check for "#" character at a first
position of given entity name and call xmlNewReference() or
xmlNewCharRef() depending on test result.
PHP 5.2.x is also affected by this problem.
Test script:
---
createElement('test');
$xml->appendChild($node);
$named = $xml->createEntityReference('entity'); // Create named
entity, works
$node->appendChild($named);
$char = $xml->createEntityReference('#xAA');// Create character
reference, doesn't work
$node->appendChild($char);
echo $xml->saveXML();
Expected result:
&entity;ª
Actual result:
--
Fatal error: Uncaught exception 'DOMException' with message 'Invalid
Character Error' in test.php:7
Stack trace:
#0 test.php(7): DOMDocument->createEntityReference('#xAA')
#1 {main}
thrown in test.php on line 7
--
Edit this bug report at http://bugs.php.net/bug.php?id=53628&edit=1
Bug #53192 [Opn->Bgs]: SimpleXML ignores XSI:TYPE attributes
Edit report at http://bugs.php.net/bug.php?id=53192&edit=1
ID: 53192
Updated by: rricha...@php.net
Reported by:jesse at eonstreet dot com
Summary:SimpleXML ignores XSI:TYPE attributes
-Status: Open
+Status: Bogus
Type: Bug
Package:SimpleXML related
Operating System: Windows 7 64bit
PHP Version:5.3.3
Block user comment: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
it works based on namespace scope so you need to tell it what namespace
is in
current scope for it to access the elements/attributes
Previous Comments:
[2010-10-28 16:01:01] jesse at eonstreet dot com
Description:
Hello,
It seems that SimpleXML removed all references to xsi:type in every
node.
XML Parser does show the xsi:type as an attribute.
The code below demonstrates this.
Test script:
---
$xmlData = 'http://www.w3.org/2001/XMLSchema-instance";
>DATA';
// Try First with SimpleXml
$xml = simplexml_load_string($xmlData);
echo "Node XSI:TYPE = ". (string)$xml->node['xsi:type'];
// Try using XML Parser
function tag_open($parser, $tag, $attributes) {
if (!empty($attributes)) { echo " Tag: $tag Atrributes:
".print_r($attributes,true); }
}
$parser = xml_parser_create();
xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, false);
xml_set_element_handler($parser, "tag_open", false);
xml_parse($parser, ltrim($xmlData));
Expected result:
Node XSI:TYPE = Test
Tag: root Atrributes: Array ( [xmlns:xsi] =>
http://www.w3.org/2001/XMLSchema-instance )
Tag: node Atrributes: Array ( [xsi:type] => Test )
Actual result:
--
Node XSI:TYPE =
Tag: root Atrributes: Array ( [xmlns:xsi] =>
http://www.w3.org/2001/XMLSchema-instance )
Tag: node Atrributes: Array ( [xsi:type] => Test )
--
Edit this bug report at http://bugs.php.net/bug.php?id=53192&edit=1
Bug #52782 [Opn->Bgs]: DOMDocument subclass forgotten using ->ownerDocument after closure
Edit report at http://bugs.php.net/bug.php?id=52782&edit=1
ID: 52782
Updated by: rricha...@php.net
Reported by:bugs dot php dot net at moesen dot nu
Summary:DOMDocument subclass forgotten using ->ownerDocument
after closure
-Status: Open
+Status: Bogus
Type: Bug
Package:DOM XML related
Operating System: GNU/Linux 2.6.26-2-686 (Debian)
PHP Version:5.3SVN-2010-09-06 (snap)
Block user comment: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is by design to minimize the system resource impact. The behavior
you
describe was the old behavior used in the domxml extension and purposely
not
duplicated. Objects wrapping the underlying XML tree live only as long
as the user
has a reference to them otherwise the only way to destroy any DOM object
would be
to de-reference every single object that wraps any portion on the
underlying xml
tree.
Previous Comments:
[2010-10-07 11:32:14] bugs dot php dot net at moesen dot nu
(Following up on e-mail correspondance with rrichards at php dot net.)
> It'd most likely due to scoping. If you create an element based on a
> subclass, it will only return the subclass as long as the element's
> object (the DOM wrapper not the underlying XML structure) no longer
> has any references.
>
> There are a couple ways to work around this:
>
> 1 - Always keep the doc object in global scope with at least 1
> reference to it. This really is only needed if you are attaching
> custom data to any custom properties.
This does indeed work around the problem, but I am not keen on polluting
the global namespace.
> 2 - The best way is to use: bool DOMDocument::registerNodeClass (
> string $baseclass , string $extendedclass )
> http://us2.php.net/manual/en/domdocument.registernodeclass.php Using
> this mehod, you can register classes to always create specific node
> types with rather than the default DOM classes so if you have any
> custom methods they will always be available i.e.
>
> class myDoc extends DOMDocument { };
>
> $doc = new myDoc();
> $doc->registerNodeClass("DOMDocument", "myDoc");
That works to a certain extent: the class is correct, but its custom
properties are lost, as mentioned in work-around 1. The ownerDocument is
an instance of MyDocument, but instead of being the original instance,
it is a new instance (without calling the constructor) with all of its
properties set to their defaults.
It seems to me that as long as there is a DOMElement, there is an
implicit reference to the original instance of the owner document
(because of $domElement->ownerDocument), so said document should not be
garbage collected.
I have uploaded a simplified test case at http://codepad.org/CBsD3eVp
[2010-09-20 13:19:34] bugs dot php dot net at moesen dot nu
Is there anything I can do to get a confirmation on this? I tried #php
on several networks, but they referred me to Freenode, where #php was
full.
[2010-09-06 15:43:15] bugs dot php dot net at moesen dot nu
Err, my apologies for not cleaning up the path names. An oversight on my
part.
[2010-09-06 15:35:59] bugs dot php dot net at moesen dot nu
Description:
We have custom XML document and element classes that extend the original
DOMDocument and DOMElement classes for convenience. There is a class
that uses an instance of XmlElement obtained via a callback specified at
construction time. That XmlElement works fine and stays that way.
However, when we get its ownerDocument outside of the closure, the
result is not an XmlDocument but a DOMDocument. I cannot see a single
reason why.
I tried several options, and it only seems to happen with that closure.
I have checked versions 5.3.1, 5.3.2, 5.3.3 and now the latest 5.3.4
snapshot compiled with './configure && make'.
Test script:
---
http://codepad.org/hvrNh86K
The original code uses a lot of namespaces and extends XmlDocument, but
this is a much more minimal test case. Also try the "Uncomment this"
code to see what /does/ work.
Expected result:
*** Calling the callback directly...
dom-fail.php:110: $container: XmlElement:
dom-fail.php:111: $container->ownerDocument: XmlDocument; debug:
object(XmlDocument)#2 (0) refcount(1){
}
*** Cal
Bug #52998 [Asn->Bgs]: memory content leak when using invalid utf-8 with XMLWriter::writeAttribute
Edit report at http://bugs.php.net/bug.php?id=52998&edit=1
ID: 52998
Updated by: rricha...@php.net
Reported by:kees at outflux dot net
Summary:memory content leak when using invalid utf-8 with
XMLWriter::writeAttribute
-Status: Assigned
+Status: Bogus
Type: Bug
Package:XML Writer
Operating System: Ubuntu 10.10
PHP Version:5.3.3
Assigned To:rrichards
Block user comment: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
You just reported the same bug to libxml2 bug system. Will be handled
there
Previous Comments:
[2010-10-06 21:25:48] paj...@php.net
Rob, does it ring a bell? It could be a bug in libxml?
[2010-10-06 20:38:47] kees at outflux dot net
This was discovered in Ubuntu, btw:
https://bugs.launchpad.net/php/+bug/655442
[2010-10-06 03:52:16] kees at outflux dot net
Description:
It seems that PHP is not correctly using libxml2's xmlwriter routines,
and allows passing in invalid utf-8 strings which are then misparsed by
libxml2, allowing memory contents to leak into the resulting output.
Test script:
---
# License: GPLv3
#
# Proof-of-concept memory content leak
$xw = new XMLWriter();
$xw->openURI('php://output');
$xw->startElement('input');
$xw->writeAttribute('value', "\xe0\x81");
$xw->endElement();
?>
Expected result:
Actual result:
--
PHP Warning: XMLWriter::writeAttribute(): string is not in UTF-8 in
/tmp/xmlwriter.php on line 12
--
Edit this bug report at http://bugs.php.net/bug.php?id=52998&edit=1
Bug #52661 [Opn->Fbk]: lookupNamespaceURI returns nothing
Edit report at http://bugs.php.net/bug.php?id=52661&edit=1
ID: 52661
Updated by: rricha...@php.net
Reported by:tim at buyplaytix dot com
Summary:lookupNamespaceURI returns nothing
-Status: Open
+Status: Feedback
Type: Bug
Package:DOM XML related
Operating System: Ubuntu maverick
PHP Version:5.3.3
Block user comment: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
most likely its due to how you are removing and adding them back in.
Need a
reproducible script to determine if this is really a bug in DOM or not
Previous Comments:
[2010-08-20 20:07:34] tim at buyplaytix dot com
Description:
Hopefully this is something that's fairly easy to see in the code.
Providing a
full working code sample will be somewhat difficult. This seems to
happen most
frequently with nodes that have been removed from the dom and added back
elsewhere.
Basically if I call lookupNamespace on a node I'm getting nothing back.
If I load
the node into SimpleXML and call getNamespaces I'm getting the namespace
as
expected.
The attached code is a workaround for the problem.
Test script:
---
private function get_namespace($node) {
$node_namespace = $node->lookupNamespaceURI($node->prefix);
if($node instanceof DomElement && $node_namespace == null &&
strpos($node->nodeName, ":") !== false) {
// must be some sort of DOM bug. Look and see if we can
figure it out from simplexml
$sxe = simplexml_import_dom($node);
$namespaces = $sxe->getNamespaces();
foreach($namespaces as $prefix => $namespace) {
if(strpos($node->nodeName, $prefix . ":") == 0) {
$node_namespace = $namespace;
break;
}
}
}
return $nodeNamespace;
}
Expected result:
I expect that if I get into the body of the if statement that I will
return a
null $node_namespace. Preferably I'd never get into the if statement.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52661&edit=1
Bug #51897 [Fbk->Bgs]: LIBXML_NOWARNING does not suppress warnings when passed to xinclude().
Edit report at http://bugs.php.net/bug.php?id=51897&edit=1
ID: 51897
Updated by: rricha...@php.net
Reported by: rquadl...@php.net
Summary: LIBXML_NOWARNING does not suppress warnings when
passed to xinclude().
-Status: Feedback
+Status: Bogus
Type: Bug
Package: DOM XML related
Operating System: Windows XP SP3
PHP Version: 5.3.2
Assigned To: rrichards
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
the underlying xinclude code is not checking those options when issuing
warnings
so needs to be fixed on the libxml2 layer. You either need to surpress
warnings
for that call or use internal error handling so they are not directly
issued to
output/log.
Previous Comments:
[2010-06-21 13:05:51] rquadl...@php.net
OOI, this code is using ...
PHP 5.3.3-RC1 (cli) (built: Jun 17 2010 22:43:29)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
and
Extension [ extension #23 libxml version ] {
- Constants [22] {
Constant [ integer LIBXML_VERSION ] { 20707 }
Constant [ string LIBXML_DOTTED_VERSION ] { 2.7.7 }
Constant [ string LIBXML_LOADED_VERSION ] { 20707 }
[2010-06-21 13:04:52] rquadl...@php.net
This is about as short as I can get. I can't work out how to get the
xinclude
working in this
example, but that is not the issue. The warning that is generated is the
issue.
Only the code
below is required - no PHPDoc or DocBook, etc.
http://www.w3.org/2001/XInclude'">
END_DTD
);
file_put_contents('my.xml', <<< END_XML
http://www.w3.org/2001/XInclude";>
Fred Bloggs
27/11/2008
Male
John Bloggs
Male
END_XML
);
echo
file_get_contents('my.dtd'), PHP_EOL, PHP_EOL,
file_get_contents('my.xml'), PHP_EOL, PHP_EOL;
$doc = new DOMDocument();
$doc->load('my.xml', LIBXML_NOENT);
var_dump($doc->xinclude(LIBXML_NOWARNING));
var_dump($doc->validate());
$doc->save('final.xml');
echo PHP_EOL, file_get_contents('final.xml');
unlink('final.xml');
unlink('my.dtd');
unlink('my.xml');
?>
Other than the XML and the DTD, the output is ...
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=my.dtd)
xpointer(id('fred')/db:birthdate) in Z:\testinc.php on line 49
int(-1)
bool(true)
The Warning is present, even though LIBXML_NOWARNING is present. I
believe that
the issue is
that xinclude processing doesn't look at the same flags as the xml
parser. But
that's just a
half-arsed guess at trying to read the c code of something I'm clearly
not
understanding 100%
Richard.
[2010-06-18 20:19:45] rricha...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
please submit a test case that doesnt require phpdoc to be pulled
[2010-05-24 12:35:56] rquadl...@php.net
Description:
This issue is in relation to http://news.php.net/php.doc/969381854
Trying to standardise the documentation in relation to including class
synopsis,
I'm including constructor and destructor synopsis via an xinclude with
an
pointer and a xfallback...
http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/desce
ndant::db:destructorsynopsis[not(@role='procedural')])">
As there is no destructor for datetime, the fallback is used (which is
empty).
All would seem to be well.
The problem is that the xinclude processing generates a warning when
using the
online documentation edit
Bug #51897 [Asn->Fbk]: LIBXML_NOWARNING does not suppress warnings when passed to xinclude().
Edit report at http://bugs.php.net/bug.php?id=51897&edit=1
ID: 51897
Updated by: rricha...@php.net
Reported by: rquadl...@php.net
Summary: LIBXML_NOWARNING does not suppress warnings when
passed to xinclude().
-Status: Assigned
+Status: Feedback
Type: Bug
Package: DOM XML related
Operating System: Windows XP SP3
PHP Version: 5.3.2
Assigned To: rrichards
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
please submit a test case that doesnt require phpdoc to be pulled
Previous Comments:
[2010-05-24 12:35:56] rquadl...@php.net
Description:
This issue is in relation to http://news.php.net/php.doc/969381854
Trying to standardise the documentation in relation to including class
synopsis,
I'm including constructor and destructor synopsis via an xinclude with
an
pointer and a xfallback...
http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/desce
ndant::db:destructorsynopsis[not(@role='procedural')])">
As there is no destructor for datetime, the fallback is used (which is
empty).
All would seem to be well.
The problem is that the xinclude processing generates a warning when
using the
online documentation editor - but not when I run this locally via
phpdoc's
configure.
I've been supplied a test script (http://news.php.net/php.doc/969381870)
which
will generate the errors locally.
And so to the bug.
In the example the xinclude() call has no parameters.
Supplying LIBXML_NOWARNING does _NOT_ suppress the warnings.
To run the test script, you will need the doc-base/manual.xml file
produced by
running the doc-base/configure.php script (part of PHPDoc).
Test script:
---
load('doc-base/manual.xml', LIBXML_NOENT);
var_dump($doc->xinclude(LIBXML_NOWARNING));
var_dump($doc->validate());
?>
Expected result:
int(-1)
bool(true)
Actual result:
--
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/desce
ndant::db:destructorsynopsis[not(@role='procedural')]) in - on line 4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetimezone')/db:refentry/db:refsec...@role='description']/d
escendant::db:destructorsynopsis[not(@role='procedural')]) in - on line
4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateinterval')/db:refentry/db:refsec...@role='description']/d
escendant::db:destructorsynopsis[not(@role='procedural')]) in - on line
4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/des
cendant::db:destructorsynopsis[not(@role='procedural')]) in - on line 4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/des
cendant::db:methodsynopsis[not(@role='procedural')]) in - on line 4
int(-1)
bool(true)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51897&edit=1
Bug #51785 [Bgs]: No way to escape quotes for XPath
Edit report at http://bugs.php.net/bug.php?id=51785&edit=1
ID: 51785
Updated by: rricha...@php.net
Reported by: pecoes at gmail dot com
Summary: No way to escape quotes for XPath
Status: Bogus
Type: Bug
Package: *XML functions
Operating System: WinXP
PHP Version: 5.3.2
Assigned To: rrichards
New Comment:
simplest way is to use php functions for comparison, like compare
htmlspecialchars escaped strings:
$dom = new DOMDocument;
$domstr = "double quote: \", single quote: '";
$dom->loadXML($domstr);
$xpath = new DOMXPath($dom);
$xpath->registerNamespace("php", "http://php.net/xpath";);
$xpath->registerPHPFunctions();
$check_string = htmlspecialchars("double quote: \", single quote: '",
ENT_QUOTES
);
$q = "/test[php:functionString('htmlspecialchars', ., 3) =
'$check_string']";
echo $q."\n";
if ($xpath->evaluate($q)->item(0)) {
echo "found\r\n";
} else {
echo "not found\r\n";
}
There is no current plan to support XPath 2.0 although possibility of
supporting
xpath variables in a future PHP version
Previous Comments:
[2010-06-18 17:05:34] pecoes at gmail dot com
We seem to misunderstand each other...
As long as there's only one type of quote - single or double - there's
no problem, but how do I escape a string with mixed quotes? How do I
quote that, so that the XPath-engine won't reject it?
[2010-06-18 16:50:06] rricha...@php.net
Jeez. Learn to properly escape strings then. I even gave you the proper
code for
your test to work. Its not a PHP bug nor a libxml2 bug so it's bogus.
Regardless
of the language you use you will hit escaping issues. If you really
think its a
bug somewhere you need to take it to the W3C.
[2010-06-18 16:33:42] pecoes at gmail dot com
Alright. It's not a PHP bug. So... what now? How do I deal with it in
PHP? Just because PHP is innocent, doesn't mean there's no need for a
fix. It's still a bug! Classifying it as "bogus" won't do a thing.
[2010-06-18 16:22:05] rricha...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You need to take into account PHP string escaping too.
$q = "/test[text()='\"']";
For more complex situations with mixed quote types, its a general
overall issue
with XPath not a PHP bug.
[2010-05-10 18:43:43] pecoes at gmail dot com
Description:
There seems to be no way to escape single or double quotes for
XPath-Queries.
given: "
/test[text()="\""] produces an error message
/test[text()="\\""] dito
/test[text()="""] finds no match
This is not a PHP-Bug, I suppose. It may be a bug in the libxml2. It
might even be a bug in the XPath Spec itself. But regardless of where
the blame lies: This is serious! How is one supposed to use user-input
in an XPath, if it cannot be escaped?
I found a work-around, but it's fugly:
$dom = new DOMDocument;
$dom->loadXML('"');
$xpath = new DOMXPath($dom);
function xquote ($str)
{
if (strpos($str, '"') === FALSE) {
return '"'.$str.'"';
}
if (strpos($str, "'") === FALSE) {
return "'".$str."'";
}
$parts = preg_split('/(")/', $str, 0,
PREG_SPLIT_DELIM_CAPTURE|PREG_SPLIT_NO_EMPTY);
array_walk($parts,
function (&$val) {
if ($val == '"') $val = "'\"'";
else $val = '"'.$val.'"';
}
);
return 'concat('.implode(',', $parts).')';
}
$q = sprintf('/test[text()=%s]', xquote('"'));
if ($xpath->evaluate($q)->item(0)) {
echo 'found'; // works!
} else {
echo 'not found';
}
Test script:
---
$dom = new DOMDocument;
$dom->loadXML('"');
$xpath = new DOMXPath($dom);
$q = '/test[text()="""]';
if ($xpath->evaluate($q)->item(0)) {
echo "found\r\n";
} else {
echo "not found\r\n";
}
$q = '/test[text()="\\""]';
if ($xpath->evaluate($q)->item(0)) {
echo "found\r\n";
} else {
echo "not found\r\n";
}
Expected result:
found
found
Actual result:
--
not found
Warning: DOMXPath::evaluate(): Invalid predicate...
Warning: DOMXPath::evaluate(): Invalid expression...
Fatal error: Call to a member function item() on non-object...
--
Edit this bug report at http://bugs.php.net/bug.php?id=51785&edit=1
Bug #51785 [Bgs]: No way to escape quotes for XPath
Edit report at http://bugs.php.net/bug.php?id=51785&edit=1
ID: 51785
Updated by: rricha...@php.net
Reported by: pecoes at gmail dot com
Summary: No way to escape quotes for XPath
Status: Bogus
Type: Bug
Package: *XML functions
Operating System: WinXP
PHP Version: 5.3.2
Assigned To: rrichards
New Comment:
Jeez. Learn to properly escape strings then. I even gave you the proper
code for
your test to work. Its not a PHP bug nor a libxml2 bug so it's bogus.
Regardless
of the language you use you will hit escaping issues. If you really
think its a
bug somewhere you need to take it to the W3C.
Previous Comments:
[2010-06-18 16:33:42] pecoes at gmail dot com
Alright. It's not a PHP bug. So... what now? How do I deal with it in
PHP? Just because PHP is innocent, doesn't mean there's no need for a
fix. It's still a bug! Classifying it as "bogus" won't do a thing.
[2010-06-18 16:22:05] rricha...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You need to take into account PHP string escaping too.
$q = "/test[text()='\"']";
For more complex situations with mixed quote types, its a general
overall issue
with XPath not a PHP bug.
[2010-05-10 18:43:43] pecoes at gmail dot com
Description:
There seems to be no way to escape single or double quotes for
XPath-Queries.
given: "
/test[text()="\""] produces an error message
/test[text()="\\""] dito
/test[text()="""] finds no match
This is not a PHP-Bug, I suppose. It may be a bug in the libxml2. It
might even be a bug in the XPath Spec itself. But regardless of where
the blame lies: This is serious! How is one supposed to use user-input
in an XPath, if it cannot be escaped?
I found a work-around, but it's fugly:
$dom = new DOMDocument;
$dom->loadXML('"');
$xpath = new DOMXPath($dom);
function xquote ($str)
{
if (strpos($str, '"') === FALSE) {
return '"'.$str.'"';
}
if (strpos($str, "'") === FALSE) {
return "'".$str."'";
}
$parts = preg_split('/(")/', $str, 0,
PREG_SPLIT_DELIM_CAPTURE|PREG_SPLIT_NO_EMPTY);
array_walk($parts,
function (&$val) {
if ($val == '"') $val = "'\"'";
else $val = '"'.$val.'"';
}
);
return 'concat('.implode(',', $parts).')';
}
$q = sprintf('/test[text()=%s]', xquote('"'));
if ($xpath->evaluate($q)->item(0)) {
echo 'found'; // works!
} else {
echo 'not found';
}
Test script:
---
$dom = new DOMDocument;
$dom->loadXML('"');
$xpath = new DOMXPath($dom);
$q = '/test[text()="""]';
if ($xpath->evaluate($q)->item(0)) {
echo "found\r\n";
} else {
echo "not found\r\n";
}
$q = '/test[text()="\\""]';
if ($xpath->evaluate($q)->item(0)) {
echo "found\r\n";
} else {
echo "not found\r\n";
}
Expected result:
found
found
Actual result:
--
not found
Warning: DOMXPath::evaluate(): Invalid predicate...
Warning: DOMXPath::evaluate(): Invalid expression...
Fatal error: Call to a member function item() on non-object...
--
Edit this bug report at http://bugs.php.net/bug.php?id=51785&edit=1
Bug #51785 [Asn->Bgs]: No way to escape quotes for XPath
Edit report at http://bugs.php.net/bug.php?id=51785&edit=1
ID: 51785
Updated by: rricha...@php.net
Reported by: pecoes at gmail dot com
Summary: No way to escape quotes for XPath
-Status: Assigned
+Status: Bogus
Type: Bug
Package: *XML functions
Operating System: WinXP
PHP Version: 5.3.2
Assigned To: rrichards
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You need to take into account PHP string escaping too.
$q = "/test[text()='\"']";
For more complex situations with mixed quote types, its a general
overall issue
with XPath not a PHP bug.
Previous Comments:
[2010-05-10 18:43:43] pecoes at gmail dot com
Description:
There seems to be no way to escape single or double quotes for
XPath-Queries.
given: "
/test[text()="\""] produces an error message
/test[text()="\\""] dito
/test[text()="""] finds no match
This is not a PHP-Bug, I suppose. It may be a bug in the libxml2. It
might even be a bug in the XPath Spec itself. But regardless of where
the blame lies: This is serious! How is one supposed to use user-input
in an XPath, if it cannot be escaped?
I found a work-around, but it's fugly:
$dom = new DOMDocument;
$dom->loadXML('"');
$xpath = new DOMXPath($dom);
function xquote ($str)
{
if (strpos($str, '"') === FALSE) {
return '"'.$str.'"';
}
if (strpos($str, "'") === FALSE) {
return "'".$str."'";
}
$parts = preg_split('/(")/', $str, 0,
PREG_SPLIT_DELIM_CAPTURE|PREG_SPLIT_NO_EMPTY);
array_walk($parts,
function (&$val) {
if ($val == '"') $val = "'\"'";
else $val = '"'.$val.'"';
}
);
return 'concat('.implode(',', $parts).')';
}
$q = sprintf('/test[text()=%s]', xquote('"'));
if ($xpath->evaluate($q)->item(0)) {
echo 'found'; // works!
} else {
echo 'not found';
}
Test script:
---
$dom = new DOMDocument;
$dom->loadXML('"');
$xpath = new DOMXPath($dom);
$q = '/test[text()="""]';
if ($xpath->evaluate($q)->item(0)) {
echo "found\r\n";
} else {
echo "not found\r\n";
}
$q = '/test[text()="\\""]';
if ($xpath->evaluate($q)->item(0)) {
echo "found\r\n";
} else {
echo "not found\r\n";
}
Expected result:
found
found
Actual result:
--
not found
Warning: DOMXPath::evaluate(): Invalid predicate...
Warning: DOMXPath::evaluate(): Invalid expression...
Fatal error: Call to a member function item() on non-object...
--
Edit this bug report at http://bugs.php.net/bug.php?id=51785&edit=1
Bug #52012 [Opn->Bgs]: DOMDocument throws Unexpected end tag error when loading valid HTML
Edit report at http://bugs.php.net/bug.php?id=52012&edit=1 ID: 52012 Updated by: rricha...@php.net Reported by: xwisdom at gmail dot com Summary: DOMDocument throws Unexpected end tag error when loading valid HTML -Status: Open +Status: Bogus Type: Bug Package: DOM XML related Operating System: Windows XP PHP Version: 5.3.2 New Comment: Behavior is due to libxml2 handling of HTML not PHP Previous Comments: [2010-06-06 23:01:07] xwisdom at gmail dot com Description: I'm getting a php warning from DOMDocument after running a test script in an attempt to load some html inside the DOM and then echo the html to the browser: Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: Unexpected end tag : strong in Entity, line: 8 in C:\www\dom-test.php on line 23 The problem is that DOMDocument::loadHTML() attempts to remove the '' tag from within a JavaScript string variable inside the tag. If I try to wrap around the content of the