php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #17779 DOMXML can't handle SYSTEM DTD
Submitted: 2002-06-16 05:47 UTC Modified: 2002-10-20 21:44 UTC
From: flying at dom dot natm dot ru Assigned:
Status: Not a bug Package: DOM XML related
PHP Version: 4.2.1 OS: Windows 2000
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: flying at dom dot natm dot ru
New email:
PHP Version: OS:

 

 [2002-06-16 05:47 UTC] flying at dom dot natm dot ru
DOMXML module can't load XML documents, containing SYSTEM DTD. Here is example:

test.xml
========
<?xml version="1.0"?>
<!DOCTYPE root SYSTEM "ext.dtd">
<root>&test;</root>

ext.dtd
=======
<!ENTITY test "***TEST***">

Loading this document as:
$xml = xmldoc(join('',file('test.xml')));

Throws warning about undefined entity &test;

Loading this document as:
$xml = xmldoc(join('',file('test.xml')),DOMXML_LOAD_COMPLETE_ATTRS);

Throws warning: Warning: failed to load external entity "ext.dtd"


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-16 07:32 UTC] derick@php.net
Does it work when you use the full path to that file in your XML file?

Derick
 [2002-06-16 07:36 UTC] flying at dom dot natm dot ru
Yes, it works well, when there is full path to external DTD specified.
 [2002-06-18 05:55 UTC] derick@php.net
Works fine for me with Linux, both the Apache module and CGI version. I think that the WIndows thing doesn't change to the correct working directory. Can you try this by putting an "echo getcwd()" just before the call to xmldoc().

Derick
 [2002-06-18 09:36 UTC] flying at dom dot natm dot ru
echo getcwd() gives me correct path, DOMXML still throws a warning, i wrote before (both with and without DOMXML_LOAD_COMPLETE_ATTRS)
 [2002-08-14 12:22 UTC] chregu@php.net
Hi

do you use apache 1.3 or apache2?

chregu
 [2002-08-14 12:24 UTC] flying at dom dot natm dot ru
I use Apache 1.3.20 with PHP run as CGI
 [2002-09-14 06:51 UTC] rrichards at digarc dot com
The problem lies with both Windows (any apache version) and Apache 2 on other systems.  On windows at least, the current working directory for libxml2 calls ends up being the apache directory.  See also bug 17390 (this bug is also a windows problem and not just Apache 2).

The example in this bug report works for loading the file as the file is passed in as file('test.xml') rather than just the filename. getcwd() will return the correct working directory as well. The problem is that the file functions (including DTD references) the domxml extension uses, are directly from libxml2, which when loaded in the mentioned environments is loaded with apache and its working directory being the apache directory.

Am unsure about a fix for this unless the current working directory can be set via libxml2 calls. Have yet to find if this is possible.

Have only confirmed this using php as an apache module.
 [2002-10-07 09:23 UTC] anton at fedosin dot ru
DOMXML does not resolve system entities, here is example:

I use Apache 1.3.26 and PHP 4.2.3 as apache module on Linux,

xml l10n.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE l:i18n SYSTEM "l10n.dtd" [
	<!ENTITY ru SYSTEM "ru.xml">
	<!ENTITY en SYSTEM "en.xml">
]>
<l:i18n xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">
&ru;
&en;
</l:i18n>

and stylesheet which just prints this xml out:

...
<xsl:param name="l10n.xml" select="document('../l10n/l10n.xml')"/>
...
<xsl:copy-of select="$l10n.xml"/>
...

I expected that the ouput will be with resolved entities, but it is not and it prints just:

<l:i18n xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0">
&ru;
&en;
</l:i18n>

whithout any warning or errors.
 [2002-10-20 21:44 UTC] sterling@php.net
not a php problem
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 14:01:32 2024 UTC