# is this a bug? - Thread: https://externals.io/message/17476 - Original archive: https://news-web.php.net/php.internals/17476 - Started by Ron Korving on 2005-08-01T07:37:29+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #17476 — Ron Korving — 2005-08-01T07:37:29+00:00 URL: https://externals.io/message/17476#17476 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. --- ## #17477 — Dmitry Stogov — 2005-08-01T11:45:52+00:00 URL: https://externals.io/message/17476#17477 · In reply to: #17476 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 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. --- ## #17478 — Wez Furlong — 2005-08-01T14:26:48+00:00 URL: https://externals.io/message/17476#17478 · In reply to: #17477 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. > > > […] --- ## #17480 — Ron Korving — 2005-08-01T18:06:05+00:00 URL: https://externals.io/message/17476#17480 · In reply to: #17478 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" 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. > > > […] --- ## #17481 — Rob Richards — 2005-08-01T18:51:18+00:00 URL: https://externals.io/message/17476#17481 · In reply to: #17480 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 --- ## #17485 — Ron Korving — 2005-08-02T08:16:00+00:00 URL: https://externals.io/message/17476#17485 · In reply to: #17481 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" 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: > > > […] a > > […] --- ## #17486 — Christian Stocker — 2005-08-02T08:23:20+00:00 URL: https://externals.io/message/17476#17486 · In reply to: #17485 > 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" schreef in bericht > news:42EE6F26.4040400@ctindustries.net... > > > […] > > a > > > […] > > -- 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 --- ## #17487 — Ron Korving — 2005-08-02T08:34:40+00:00 URL: https://externals.io/message/17476#17487 · In reply to: #17486 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" schreef in bericht news:42EF2D78.20105@bitflux.ch... > > > > > […] for > > […] this is > > […] > > 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 > > > […] has > > […] from > > […] > > -- > 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 --- ## #17490 — Nuno Lopes — 2005-08-02T12:42:53+00:00 URL: https://externals.io/message/17476#17490 · In reply to: #17486 > > > […] > > 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: Behind the Parser 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 --- ## #17492 — Rob Richards — 2005-08-02T13:28:55+00:00 URL: https://externals.io/message/17476#17492 · In reply to: #17490 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/..? --- ## #17500 — Nuno Lopes — 2005-08-02T16:17:58+00:00 URL: https://externals.io/message/17476#17500 · In reply to: #17492 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: > > > […] > > .... > > > […]