After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 614333 - ResponseXML is null via browser that uses libxml2
ResponseXML is null via browser that uses libxml2
Status: RESOLVED OBSOLETE
Product: libxml2
Classification: Platform
Component: general
git master
Other Linux
: Normal major
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2010-03-30 08:20 UTC by Jean Louis [reporter][developer]
Modified: 2021-07-05 13:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
c program that shows the error (1.45 KB, text/x-csrc)
2010-03-31 10:43 UTC, arno
Details

Description Jean Louis [reporter][developer] 2010-03-30 08:20:12 UTC
Hi,

Like I say on http://www.twotoasts.de/bugs/index.php?do=details&task_id=793

There is a problem between these two versions of libxml2 : 2.7.3-r1.5 and 2.7.7-r6.0.5

That seems to be a problem with the encoding type of xml response.

Thanks.
Comment 1 Daniel Veillard 2010-03-30 14:37:53 UTC
Provide the input as an attachement and how to reproduce the
bug with xmllint (or a standalone C program).

paphio:~/XML -> cat > tst.xml
<?xml version="1.0" encoding="ISO-8859-15"?>
<pere err="0">
<date type="ug">
<mday>30</mday>
<mon>3</mon>
<year>2010</year>
<hour>9</hour>
<min>8</min>
<sec>13</sec>
</date>
</pere>
paphio:~/XML -> xmllint tst.xml
<?xml version="1.0" encoding="ISO-8859-15"?>
<pere err="0">
<date type="ug">
<mday>30</mday>
<mon>3</mon>
<year>2010</year>
<hour>9</hour>
<min>8</min>
<sec>13</sec>
</date>
</pere>
paphio:~/XML -> 

  I can't reproduce your problem !

Daniel
Comment 2 Jean Louis [reporter][developer] 2010-03-31 10:31:00 UTC
Hi Daniel,

Like I say on http://www.twotoasts.de/bugs/index.php?do=details&task_id=793,

the windows version doesn't have the problem, then I also can't reproduce the problem with xmllint and libxml2 (2.7.6) under windows.

Like Arno say on midori bug report, when you change the encoding from latin9 to utf8, the problem disappear.

Under my angstrom linux distribution, I only downgrade the libxml2 library from 2.7.7-r6.0.5 to 2.7.3-r1.5 and the bug doesn't appear with latin9 encoding.

May be a problem of define of linux platform between these versions ?

Bye, Jean-Louis.
Comment 3 arno 2010-03-31 10:43:49 UTC
Created attachment 157570 [details]
c program that shows the error

Hi, the bug appears when xml string is converted to utf16 then feed to sax parser.
Comment 4 Daniel Veillard 2010-03-31 13:54:19 UTC
Well you have an XML which states that its encoding is "ISO-8859-15"
but it's actually encoded as UTF-16, and when creating the parser
you don't tell the parser (at creation time) that the encoding is
provided by the environment. I consider this a fatal error based
on the XML spec appendix F

http://www.w3.org/TR/REC-xml/#sec-guessing

paphio:~/XML -> ./tst 
error: Char 0x0 out of allowed range
error: xmlParseStartTag: invalid element name
result: 68
paphio:~/XML -> 

calling xmlSwitchEncoding() on the parser back is not a proper way to
try to handle the mismatch. You must pass the known encoding string
at parser creation time

I guess under Windows you don't have "ISO-8859-15" support or something,
which makes it work but that code is broken.

Daniel
Comment 5 Jean Louis [reporter][developer] 2010-03-31 16:16:38 UTC
Hi Daniel,

Thanks for your help.

For information, probably related to https://bugs.webkit.org/show_bug.cgi?id=30508

Bye.
Comment 6 Daniel Veillard 2010-03-31 16:40:38 UTC
Hum, the problem is that by using 

xmlCreatePushParserCtxt()

which is one of the few parser API not taking in a context encoding
it's basically impossible to cleanly tell that the original encoding
had been overriden.
I looked quickly at the patch posted on the webkit bug, and honnestly
I find that horrible, not the patch specifically, but the fact that
original encoding, and apparently the XMLDecl have been removed before
feeding the parser.
Also the comment 
   // Hack around libxml2's lack of encoding overide support by manually
is just wrong, libxml2 provides the overriding support from Appendix F
except the xmlCreatePushParserCtxt() is an old interface not providing it.

Daniel
Comment 7 Alexey Proskuryakov 2010-03-31 18:01:46 UTC
What is the better way for WebKit to invoke the parser? See the thread at <http://mail.gnome.org/archives/xml/2006-February/msg00052.html> and specifically <http://mail.gnome.org/archives/xml/2006-February/msg00060.html> - it didn't look like there was a better solution at the moment.
Comment 8 Jean Louis [reporter][developer] 2010-04-04 10:19:30 UTC
Hi Daniel,

Have you a response for "current" version of libxml2 to Alexey's comment ?

"Who" has the bug (webkit or libxml2) ?

Thanks for you help.
Comment 9 Jean Louis [reporter][developer] 2010-04-29 10:02:34 UTC
Hi Daniel,

Have you response(s) to my questions ?

Thanks.
Comment 10 Jean Louis [reporter][developer] 2010-08-29 21:16:50 UTC
Hi,

https://bugs.webkit.org/show_bug.cgi?id=30508 is fixed.

to be continued ...
Comment 11 GNOME Infrastructure Team 2021-07-05 13:24:39 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/libxml2/-/issues/

Thank you for your understanding and your help.