Everything

php

is this a bug?

php.internals

Ron Korving

21 years ago

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.

Dmitry Stogov

21 years ago

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.

Wez Furlong

21 years ago

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.

On 8/1/05, Dmitry Stogov <dmitry@zend.com> wrote:

Ron Korving

21 years ago

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.

On 8/1/05, Dmitry Stogov <dmitry@zend.com> wrote:

Rob Richards

21 years ago

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:

Ron Korving

21 years ago

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

Christian Stocker

21 years ago

On 2.8.2005 10:16 Uhr, Ron Korving wrote:

> 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 from
>
> a
>
>>>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

Ron Korving

21 years ago

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...

>
>
> On 2.8.2005 10:16 Uhr, Ron Korving wrote:
> > 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

from

Nuno Lopes

21 years ago

> On 2.8.2005 10:16 Uhr, Ron Korving wrote:
>> 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

Rob Richards

21 years ago

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:

....

Nuno Lopes

21 years ago

OK thanks for the info. I'll add that to the documentation.
Nuno

----- Original Message -----