GNOME Bugzilla – Bug 552479
xinclude with parse="text" does not use the selected externalEntityLoader
Last modified: 2012-05-10 13:02:27 UTC
Please describe the problem: Running: xmllint --nonet --xinclude test.xml on <?xml version="1.0" encoding="utf-8"?> <root> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="http://wikipedia.sevenval.com/sitemap.xml" parse="text"/> </root> loads the referenced document, even though it is on the net. Without parse="text" it works as expected Steps to reproduce: See above Actual results: The text ist loaded from the net Expected results: No loading Does this happen every time? Yes Other information: It seems to me for parse="text" the Loader set by xmlSetExternalEntityLoader is ignored/ not used
Created attachment 118954 [details] [review] Proposed Patch for bug 552479 With the patch it works as expected
Created attachment 118992 [details] [review] Proposed Patch for bug 552479 (fixed)
Okay I looked at this but unfortunately the patch breaks XInclude, that can be seen easilly just by running the regression tests with it applied. There was a memory leak on the return(-1) which was trivial to fix, but the real problem is that it now ignores the encoding provided (if provided) making XInclude non conformant anymore. A better solution using the general resolver is still the right way to go, but it should plug the encoding converter. I didn't really had time to chase it, so it's still not fixed, unfortunately, thanks for the initial patch, but it's not usable as-is, Daniel
As is predictable from the above exchange, the bug persists for libxml2 2.7.3-1 under cygwin.
Created attachment 213316 [details] [review] Use externalEntityLoader, set the encoder Building off the previous patch, but also setting the encoder. This passed 'make tests' for me.
Comment on attachment 213316 [details] [review] Use externalEntityLoader, set the encoder Looks fine to me, please submit upstream :-)
Thanks Shaun, I commited it :-) http://git.gnome.org/browse/libxml2/commit/?id=4cf7325e1f5d6b727bae8f01851c759e49a9d05d thanks again ! Daniel