When I receive a warning that an XSD file could not be opened, it urlencodes
the filepath. That doesn't make sense to me...
Example:
Warning: I/O warning : failed to load external entity
"/var/www/my%20test%20schema.xsd" in /var/www/test.php on line 10
Is this a bug?
Ron
PS: Weird thing is that this file actually does exist at that place, but
that's another problem I'm gonna have to look into.
Hi Ron,
This is probably a bug.
I don't know if it easy fixable.
You can post it into bugs.php.net, and I'll look into it (when I'll have
time for it).
Thanks. Dmitry.
-----Original Message-----
From: Ron Korving [mailto:r.korving@xit.nl]
Sent: Monday, August 01, 2005 11:37 AM
To: internals@lists.php.net
Subject: [PHP-DEV] is this a bug?When I receive a warning that an XSD file could not be
opened, it urlencodes the filepath. That doesn't make sense to me...Example:
Warning: I/O warning : failed to load external entity
"/var/www/my%20test%20schema.xsd" in /var/www/test.php on line 10Is this a bug?
Ron
PS: Weird thing is that this file actually does exist at that
place, but that's another problem I'm gonna have to look into.
Remember that spaces are illegal in URLs, so it seems perfectly fine
to have it encoded.
Whether the behaviour you're seeing is a bug, I'll leave to people
that know the code to decide :)
--Wez.
Hi Ron,
This is probably a bug.
I don't know if it easy fixable.
You can post it into bugs.php.net, and I'll look into it (when I'll have
time for it).Thanks. Dmitry.
-----Original Message-----
From: Ron Korving [mailto:r.korving@xit.nl]
Sent: Monday, August 01, 2005 11:37 AM
To: internals@lists.php.net
Subject: [PHP-DEV] is this a bug?When I receive a warning that an XSD file could not be
opened, it urlencodes the filepath. That doesn't make sense to me...Example:
Warning: I/O warning : failed to load external entity
"/var/www/my%20test%20schema.xsd" in /var/www/test.php on line 10Is this a bug?
Ron
PS: Weird thing is that this file actually does exist at that
place, but that's another problem I'm gonna have to look into.
Yes, spaces are illegal.. Thing is though, the output of the warning has
nothing to do with urls (unless it just assumes the stream is always from a
remote source or something).
I'll post a bugreport.
Ron
"Wez Furlong" kingwez@gmail.com wrote in message
news:4e89b4260508010726198d1f45@mail.gmail.com...
Remember that spaces are illegal in URLs, so it seems perfectly fine
to have it encoded.
Whether the behaviour you're seeing is a bug, I'll leave to people
that know the code to decide :)
--Wez.
Hi Ron,
This is probably a bug.
I don't know if it easy fixable.
You can post it into bugs.php.net, and I'll look into it (when I'll have
time for it).Thanks. Dmitry.
-----Original Message-----
From: Ron Korving [mailto:r.korving@xit.nl]
Sent: Monday, August 01, 2005 11:37 AM
To: internals@lists.php.net
Subject: [PHP-DEV] is this a bug?When I receive a warning that an XSD file could not be
opened, it urlencodes the filepath. That doesn't make sense to me...Example:
Warning: I/O warning : failed to load external entity
"/var/www/my%20test%20schema.xsd" in /var/www/test.php on line 10Is this a bug?
Ron
PS: Weird thing is that this file actually does exist at that
place, but that's another problem I'm gonna have to look into.
The warning is being issued from libxml and the URL (which it encodes
internally) is just there to inform you that it had problems dealing
with the external entitity. Either surpress the errors when calling
whichever function or you can use the new error handling for xml in 5.1
which wont issue/display errors directly but any can be retrieved after
the function call.
Rob
Ron Korving wrote:
Yes, spaces are illegal.. Thing is though, the output of the warning has
nothing to do with urls (unless it just assumes the stream is always from a
remote source or something).I'll post a bugreport.
Ron
Shouldn't PHP suppress this warning then? Right now 3 warnings are shown for
just one bad statement. I think one warning would suffice. Of course this is
all rather unimportant and very low-priority, but I still think it's a
situation that could be improved.
You can see the warnings at http://bugs.php.net/bug.php?id=33951
Ron
"Rob Richards" rrichards@ctindustries.net schreef in bericht
news:42EE6F26.4040400@ctindustries.net...
The warning is being issued from libxml and the URL (which it encodes
internally) is just there to inform you that it had problems dealing
with the external entitity. Either surpress the errors when calling
whichever function or you can use the new error handling for xml in 5.1
which wont issue/display errors directly but any can be retrieved after
the function call.Rob
Ron Korving wrote:
Yes, spaces are illegal.. Thing is though, the output of the warning has
nothing to do with urls (unless it just assumes the stream is always from
a
remote source or something).I'll post a bugreport.
Ron
Shouldn't PHP suppress this warning then? Right now 3 warnings are shown for
just one bad statement. I think one warning would suffice. Of course this is
all rather unimportant and very low-priority, but I still think it's a
situation that could be improved.You can see the warnings at http://bugs.php.net/bug.php?id=33951
AFAICS these are all libxml2 warnings. We would have to start
intercepting those warnings and decide which one we want to show and
which not... Too much hassle IMHO. In your scenario, which should be shown?
And with the new libxml error handler code in PHP 5.1, the developer can
decide, what he wants to show and what not... See
http://www.php.net/libxml_use_internal_errors
and
http://php5.bitflux.org/xml5_1/slide_13.php
for some explenation and examples
chregu
Ron
"Rob Richards" rrichards@ctindustries.net schreef in bericht
news:42EE6F26.4040400@ctindustries.net...The warning is being issued from libxml and the URL (which it encodes
internally) is just there to inform you that it had problems dealing
with the external entitity. Either surpress the errors when calling
whichever function or you can use the new error handling for xml in 5.1
which wont issue/display errors directly but any can be retrieved after
the function call.Rob
Ron Korving wrote:
Yes, spaces are illegal.. Thing is though, the output of the warning has
nothing to do with urls (unless it just assumes the stream is always froma
remote source or something).
I'll post a bugreport.
Ron
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
The 5.1 error handling looks very promising. For me personally, the 3
warnings are no problem. I want to suppress all 3 of them (so I don't really
care if I suppress 1 or 3 and I don't really care how these warnings are
formatted). But I figured what goes for me, doesn't necessarily go for the
rest of the world. Besides that, don't we all want to see PHP become better
and better? :)
Of the 3 warnings:
(1) Warning: I/O warning : failed to load external entity
"/non%20existant%20file.xsd" in
/www/admin/dev/bugreports/dom-validate/index.php on line 4
(2) Warning: xmlSchemaParse: could not load '/non existant file.xsd'. in
/www/admin/dev/bugreports/dom-validate/index.php on line 4
(3) Warning: Invalid Schema in
/www/admin/dev/bugreports/dom-validate/index.php on line 4
I would prefer to just see warning of the highest level (3), but it does
lack the information that says the actual XSD-file is missing. Again, for me
personally, this requires no fix.
Ron
"Christian Stocker" chregu@bitflux.ch schreef in bericht
news:42EF2D78.20105@bitflux.ch...
Shouldn't PHP suppress this warning then? Right now 3 warnings are shown
for
just one bad statement. I think one warning would suffice. Of course
this is
all rather unimportant and very low-priority, but I still think it's a
situation that could be improved.You can see the warnings at http://bugs.php.net/bug.php?id=33951
AFAICS these are all libxml2 warnings. We would have to start
intercepting those warnings and decide which one we want to show and
which not... Too much hassle IMHO. In your scenario, which should be
shown?And with the new libxml error handler code in PHP 5.1, the developer can
decide, what he wants to show and what not... See
http://www.php.net/libxml_use_internal_errors
and
http://php5.bitflux.org/xml5_1/slide_13.php
for some explenation and exampleschregu
Ron
"Rob Richards" rrichards@ctindustries.net schreef in bericht
news:42EE6F26.4040400@ctindustries.net...The warning is being issued from libxml and the URL (which it encodes
internally) is just there to inform you that it had problems dealing
with the external entitity. Either surpress the errors when calling
whichever function or you can use the new error handling for xml in 5.1
which wont issue/display errors directly but any can be retrieved after
the function call.Rob
Ron Korving wrote:
Yes, spaces are illegal.. Thing is though, the output of the warning
has
nothing to do with urls (unless it just assumes the stream is always
froma
remote source or something).
I'll post a bugreport.
Ron
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
Shouldn't PHP suppress this warning then? Right now 3 warnings are shown
for
just one bad statement. I think one warning would suffice. Of course this
is
all rather unimportant and very low-priority, but I still think it's a
situation that could be improved.You can see the warnings at http://bugs.php.net/bug.php?id=33951
AFAICS these are all libxml2 warnings. We would have to start
intercepting those warnings and decide which one we want to show and
which not... Too much hassle IMHO. In your scenario, which should be
shown?And with the new libxml error handler code in PHP 5.1, the developer can
decide, what he wants to show and what not... See
http://www.php.net/libxml_use_internal_errors
and
http://php5.bitflux.org/xml5_1/slide_13.php
for some explenation and examples
The most interesting example is at http://php.net/libxml_get_errors
But while I was reading again the example I wrote, I found that libxml
always returns column 0:
<?php
libxml_use_internal_errors(true);
$xmlstr = <<< XML
<?xml version='1.0' standalone='yes'?>
<movies > <movie> <titles>PHP: Behind the Parser</title> </mdovie></movies>
XML;
$doc = simplexml_load_string($xmlstr);
$xml = explode("\n", $xmlstr);
print_r(libxml_get_errors());
?>
Array
(
[0] => LibXMLError Object
(
[level] => 3
[code] => 76
[column] => 0
[message] => Opening and ending tag mismatch: titles line 2 and
title
[file] =>
[line] => 2
)
[1] => LibXMLError Object
(
[level] => 3
[code] => 76
[column] => 0
[message] => Opening and ending tag mismatch: movie line 2 and
mdovie
[file] =>
[line] => 2
)
)
This seems to be a bug to me, or the column stuff will only work when
validating with a dtd/..?
Nuno
Column numbers in errors are not yet implemented everywhere in libxml
and 0 is often returned.
Rob
Nuno Lopes wrote:
The most interesting example is at http://php.net/libxml_get_errors
But while I was reading again the example I wrote, I found that libxml
always returns column 0:
....
This seems to be a bug to me, or the column stuff will only work when
validating with a dtd/..?
OK thanks for the info. I'll add that to the documentation.
Nuno
----- Original Message -----
Column numbers in errors are not yet implemented everywhere in libxml
and 0 is often returned.Rob
Nuno Lopes wrote:
The most interesting example is at http://php.net/libxml_get_errors
But while I was reading again the example I wrote, I found that libxml
always returns column 0:....
This seems to be a bug to me, or the column stuff will only work when
validating with a dtd/..?