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 104790 - encoding and XML through HTTP
encoding and XML through HTTP
Status: VERIFIED FIXED
Product: libxslt
Classification: Platform
Component: general
1.0.10
Other other
: Normal normal
: ---
Assigned To: Daniel Veillard
Daniel Veillard
Depends on:
Blocks:
 
 
Reported: 2003-01-30 10:22 UTC by Dominique Hazaël-Massieux
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dominique Hazaël-Massieux 2003-01-30 10:22:31 UTC
Hi DV,

Again, I'm not sure if this is a bug in xsltproc or a bug in my
understanding of XML encoding detection.
If I call xsltproc on an XML file served with an HTTP header setting its
encoding to iso-8859-1 (such as
http://www.w3.org/2002/02/acl-test/text.xml), but with no <?xml?>
declaration in it, it stops on any iso-8859-1 encoded character (in the
above example, "à"). My understanding of the XML Rec is that the transport
layer is authoritative on this matter, so I would think xsltproc should
take the charset parameter into account, but I could be wrong.

(Note that the problem also appears for an XHTML file served as text/html;
charset=iso-8859-1, but this is probably a corner case... I'm not sure how
libxslt handles HTTP MIME-Type generally speaking).

Sorry if this is wrong
Comment 1 Daniel Veillard 2003-01-30 13:53:55 UTC
Right, it's a bug. But I won't fix it, first libxml2 internal
APIs don't forward the HTTP header all the way up in the stack to
the XML parser, and second trusting the HTTP headers is not
reliable anyway for stable processing. It's a corner case, 
a very dangerous one, I don't think I will fix it.

Daniel
Comment 2 Daniel Veillard 2003-10-19 10:41:49 UTC
With the overall big changes for 2.6.0, I decided to cleanup the
HTTP/parser interractions and fixed this bug as part of this process,
so this should be fixed in CVS RSN, and be available as part of 2.6.0

Daniel 
Comment 3 Daniel Veillard 2003-10-21 12:28:16 UTC
This should be fixed in release libxml2-2.6.0,
                                                                     
          
  thanks,
                                                                     
          
Daniel