Closed Bug 521301 Opened 15 years ago Closed 8 years ago

[XHR2] responseXML document contains parse errors when response entity body is null.

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: phnxmyst, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

When performing a post/get/put/delete request using an XMLHttpRequest and the response entity body is null and content-type header is not set, "no element found" is thrown in the Error Console and parse errors appear in the responseXML document.

In the w3c documentation (http://www.w3.org/TR/XMLHttpRequest/#xml-response-entity-body), please refer to algorithm step one and to http://www.w3.org/TR/XMLHttpRequest/#the-responsexml-attribute.

Reproducible: Always

Steps to Reproduce:
1. click on the link provided (http://carbonetworks.com:8008)
2. open up the Error Console on the browser
3. click on the Make Request button
Actual Results:  
A "no element found" is displayed in the Error Console and an incorrect xml document (contains parse errors) is set for the responseXML.

Expected Results:  
There are no errors in the Error Console and the responseXML is set to null (according to http://www.w3.org/TR/XMLHttpRequest/#the-responsexml-attribute).

Restlet server (restlet.org) is being used on the backend and that is why no content-type is being set.
I've
I've also seen this bug.  I have the server returning a 204 with an empty response body after a POST resulting in the 'no element found' error in the error console.
I see this as well (using Firefox 4.0 beta6).  It occurs for me when setting status to "204" (No Content).  Even if I try to set the content-type, the only headers that get returned to XMLHttpRequest (from Apache Tomcat 6.0.14) are....

Server: Apache-Coyote/1.1
Date: Tue, 09 Nov 2010 20:34:03 GMT


I think Firefox is presuming XML in the absence of the "Content-Type" header and reporting the "no element found" error in the error console.  Updating status to "New".

Jake
Status: UNCONFIRMED → NEW
Ever confirmed: true
Will this ever be fixed in any firefox version?
Component: General → DOM: Mozilla Extensions
Product: Firefox → Core
QA Contact: general → general
This is still happening. It's reasonable if the status had been 200, for example, but it's the reverse of the correct behaviour if it was 204 or 205 (in which case having "response found for no-content status" or even "element found" would be a useful thing to be warned about).

For the most part I've found it to be harmless - I can still detect the 204 and no the request succeeded - though I haven't had to look at any headers in those cases in my own code, so I haven't looked at the impact there.

It is though a nuisance to have any real errors hidden by this, and can lead to false bug-reports and complaints if users see this in the console.
Henri:

You seem to know the XHR code pretty well.

Would this be easy to fix?

It's quite annoying.
(In reply to Liz Vinkle from comment #0)
> content-type header is not set

This is odd. I don't immediately see a reason in the code why it would try to parse XML without Content-Type.

(In reply to Michael Kaply (mkaply) from comment #6)
> Would this be easy to fix?

Not parsing when the response code is one that MUST NOT be accompanied by a response entity body would be pretty easy.

As a workaround, if you know on the client side that the server is going to say 204 anyway, you should be able to suppress the error by setting .responseType = "text".
Had the same problem with REST calls to GoggleCalendar. Any update of an event send to GCAl was responded with a similar "XML no element found" error thrown on the console. It was more worse because the error console disclosed the whole login string including password!

Just adding .responseType = "" (only an empty string) fixed the problem!
(In reply to Günter from comment #8)

Have to correct myself. It's NOT fixing the problem!

Also it seems to be a problem with GoggleCalendar only (other CalDAV servers like 'fruux' or 'ownCloud' return content details) I can't find a method to have XMLHttpRequest not to throw an error to the console like this:
> Error: no element found
> Source file: https://{--NAME--}%40googlemail%2Ecom:{--PASSWORD--}@www.google.com/calendar/dav/{--CALENDAR_ID--}@group.calendar.google.com/events/1362006000000-915510352.ics
> Line: 1

Tracing the response for CalDAV 'PUT' request gives:
with 'GCalendar':
> 204 No Content
> Server:  GSE
> X-Firefox-Spdy:  3

with 'fruux.com':
> 204 No Content
> Server:  nginx
> Content-Type:  text/html
> Content-Length:  0
> I don't immediately see a reason in the code why it would try to parse XML without
> Content-Type.

We set a content-type hint when opening the channel; no content type sent by the server means text/xml is assumed.  Note that this matches the behavior http://www.w3.org/TR/XMLHttpRequest2/#document-response-entity-body calls for as far as I can tell.
The description for XHR says responseType="" and responseType="text" are both string type. But (for me) only changing the code to responseType="text" worked. Had also to change the 'onSucess' parameters not to ask for .responseXML.
This bug causes significant problems in using 204's as a response for AJAX requests.  See this thread at jQuery tickets for a deeper explanation with screenshots:

http://bugs.jquery.com/ticket/13654
Here is a test case:

https://gist.github.com/ojak/5247073
Component: DOM: Mozilla Extensions → DOM
Gecko has this old feature where XML parser outputs a document with error info if parsing fails. This is wrong per spec and other implementations

Test cases:
http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/responsexml-basic.htm - second subtest is this bug
Blocks: xhr2pass
Summary: responseXML document contains parse errors when response entity body is null. → [XHR2] responseXML document contains parse errors when response entity body is null.
Blocks: 411060
Also causing this issue reported to jQuery: http://bugs.jquery.com/ticket/13450
No, it's not.  That's a different issue.
I'm confirming seeing this on FF23 and FF27 when using XHR to preform a GET request which responds with a 304, no body, content-type header. This is the same as bug 411060 which has been marked as a duplicate of this bug.

The impact of this is cached JSON XHR responses simply don't work any more on my empty body responses which sends a 304 with no content-type as per the spec... due to the fact it's throwing XML parsing errors.
Sorry, I misrepresented in my previous comment. It's not preventing execution of the code, but it is writing the error to console.
Brian, if you're sending a 304 after we (the Gecko cache) asked for whether a cached version can be used, the XHR won't ever get empty data: it'll get whatever 200 response we have cached.

If the 304 is sent blindly even if we didn't do a conditional request, based on the page sending a conditional header, then of course we can't provide the page with the data... and bug 411060 as you noted covers the console spew.
Please note, this bug is about HTTP 204 and not HTTP 304! It has noting to do with caching..., but with empty ajax content, i.e. 204 which is quite legal and not an error
This should be resolved now that bug 289714 is fixed (indeed, the web platform test in question passes). The XHR's responseXML will be null and a parsing failure will simply be logged to the web console instead.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.