243089 - XMLHttpRequest throws error if response content-type contains the string 'xml' with additional text

Status: RESOLVED WORKSFORME

(Core :: XML, defect)

Description

[Damion Alexander]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040508

while developing a XUL app, I tried using XMLHttpRequest to POST data to a CGI.
If the CGI returns a "content-type" of '*/*xml*' XMLHttpRequest will throw an
error and not access the data.  However if the content-type is '*/xml' or
anything else it works fine.  

For example if the the content-type is any one of:
"application/xml+atom" 
"text/xml+atom"
"application/xml+html"
"application/thisisjustjunkxml"
"application/hiddenxmlstring"

An error will be thrown.  However:

"text/xml"
"application/xml"
and the special case: "application/xhtml+xml"

works.

It's not specific to one particular CGI.  I have been able to reproduce the
problem with a very simple perl CGI.  

I was using 1.7a from source, and confirmed with 1.7rc1 downloaded 5/8/2004. 
Compiled: ./configure  --prefix=/home/funkknight/development --enable-xpctools
--enable-extensions --enable-default-toolkit=gtk2 --enable-xft --enable-crypto
--enable-debug-modules





Reproducible: Always
Steps to Reproduce:
1. Create XUL app with one button.
2. Attach following script to button
function testMimeBug() {
	var t = new XMLHttpRequest();
	t.open("GET","http://localhost/cgi-bin/testme.pl",false);
	t.send(null);
}
3. Create perl CGI (named: testme.pl):
#!/usr/bin/perl

use CGI;
use Data::Dumper;

my $q = new CGI;
print $q->header(-type => "application/xml");

my @mine = $q->http();

foreach $hello (@mine) {
        print "$hello :  " ;
        print $q->http($hello);
        print  "<br /> \n";
}
print "<p /><p />";

4. Run XUL app and trigger function via button
5 Change  content-type to something different in perl CGI
6. goto 4
Actual Results:  
If the content type contains anything with XML like described I get the
following error (dumped to the console that started mozilla):

###!!! ASSERTION: OnDataAvailable implementation consumed no data: 'Error', file
nsInputStreamPump.cpp, line 451
Break: at file nsInputStreamPump.cpp, line 451
JavaScript error: 
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.send]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame :: chrome://disatom/content/disatom.js
:: testMimeBug :: line 87"  data: no]


Expected Results:  
1. shouldn't error on when xml is embedded in content-type string
2. Not sure of the standards on parsing XML via content-types but me thinks it
should at least consume the data for XMLHttpRequest.responseText.

about:buildconfig

Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.2.3 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align
-Wno-long-long -pedantic -pthread -pipe
c++ 	gcc version 3.2.3 	-fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe
-I/usr/X11R6/include

Configure arguments
--prefix=/home/funkknight/development --enable-xpctools --enable-extensions
--enable-default-toolkit=gtk2 --enable-xft --enable-crypto --enable-debug-modules

Comment 1

[Boris Zbarsky [:bzbarsky]]

See
http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#1190

If the type contains the string "xml" we actually take a shot at parsing it as
XML (we don't bother otherwise).  If the type is not a valid XML type, something
else throws an exception, though....  Perhaps we should be catching it in this
code and not propagating it to caller?

Comment 2

[Martin Honnen]

I think I have run into what this bug is about while trying to load SVG images
with MIME type image/svg+xml thus I am going to confirm this bug.
I will attach a test case on bugzilla but for now try the test case at
http://home.arcor.de/martin.honnen/mozillaBugs/XMLHttpRequest/test20040706.html

Comment 3

[Martin Honnen]

Attachment: XML file used in test case, to be served as text/xml which works

Comment 4

[Martin Honnen]

Attachment: XML file used in test case, served as image/svg+xml which causes error

Comment 5

[Martin Honnen]

Attachment: test case which shows Mozilla fails to load image/svg+xml content with XMLHttpRequest

Comment 6

[Martin Honnen]

The test case http://bugzilla.mozilla.org/attachment.cgi?id=152416&action=view
shows the problem with the Mozilla 1.7 release (Mozilla/5.0 (Windows; U; Windows
NT 5.1; en-US; rv:1.7) Gecko/20040616) as well as with Firefox 0.9 (Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9).
I will try to grab a nightly trunk build to check whether the problem exists
there too.

Comment 7

[Martin Honnen]

The test case 
http://bugzilla.mozilla.org/attachment.cgi?id=152416&action=view
works flawlessly with Mozilla 1.8a2 (Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8a2) Gecko/20040705) so somehow the problem seems to be fixed there.
Does anyone have an idea what fixed this?
From my test case I should mark this bug as relate to version Mozilla 1.7 branch
only however bugzilla only offers 1.0 branch, 1.4 branch, other branch, and
trunk so leave version as trunk until bugzilla is updated to offer version 1.7
branch.

Comment 8

[Martin Honnen]

Is there any difference between Mozilla 1.7 in
http://lxr.mozilla.org/mozilla1.7/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#1190
and the Mozilla trunk in
http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#1193
?

Comment 9

[Martin Honnen]

Sorry for the spam, somehow while reloading the bug display page I must have
unintentionally changed OS to LINUX while it should be All.

Comment 10

[Thomas Wisniewski]

An exception is not thrown anymore for the example code given, and probably has not for a long time now.

Gecko now follows the XHR spec, and will try to parse the response as a document if a Content-Type is given as one of: text/html, text/xml, application/xml, or anything ending in +xml. Otherwise will simply parse the responseText and leave it up to the user to parse it as XML if deemed appropriate.

As such, I'm closing this ticket as WORKSFORME, since any problem here has almost certainly been long since resolved.