Last Comment Bug 411060 - XmlHttpRequest parsing of 304 error returns
: XmlHttpRequest parsing of 304 error returns
Status: RESOLVED DUPLICATE of bug 884693
Product: Core
Classification: Components
Component: XML (show other bugs)
: Trunk
: All All
-- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
: 720801 (view as bug list)
Depends on: 521301
  Show dependency treegraph
Reported: 2008-01-06 15:44 PST by Robert Accettura [:raccettura]
Modified: 2016-09-19 20:57 PDT (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Robert Accettura [:raccettura] 2008-01-06 15:44:22 PST
This is a spin-off of bug 307049.

If an xmlHttpRequest sets a "If-Modified-Since" header (rfc2616 sec14.25) as such:
request.setRequestHeader("If-Modified-Since", lastModDate);

And the response is a 304 (rfc2616 sec10.3.5) it returns no data.  xmlHttpRequest still tries to parse the response, resulting in an xml error.

Currently the best work around I can think of is to use:
// Make it text/plain so there's no parsing ahead of it's time


req.onreadystatechange = function (aEvt) {
  if(req.readyState == 4 && req.status == 200){
    var parser = new DOMParser();
    var dom = parser.parseFromString(theString, "text/xml");
    req.responseXML = dom;
  } else if(req.status == 304){
    // No parsing since no data.

by setting the content-type to text/plain xmlHttpRequest will not parse the response leaving it up to the customer to create a dom parser and pass it through.

It's my belief that a 304 should not be parsed since it's understood in the http specs that a 304 response contains no data.  request.responseXML should simply be null or "" and request.status = 304.  

The parser shouldn't attempt to parse something with a length of 0 characters.  There's no real "error" here since the response is valid per http/1.1 specs.  The error is in the invocation of the parser.

There is a workaround as demonstrated above, but it's unintuitive and excessive.  xmlHttpRequest shouldn't throw an error for a valid response. 

As for other non-2xx responses, it should be parsed as text/xml (unless overrideMimeType is used) since data is returned.  If a response could be non-xml it's up to the customer to handle that correctly.
Comment 1 User image Boris Zbarsky [:bz] (still a bit busy) 2008-01-06 18:39:53 PST
Need spec work here for non-2xx response handling in general.  I'm not sure how much sense it makes to just go ahead and parse 404s, for example.
Comment 2 User image Robert Accettura [:raccettura] 2008-01-06 19:28:33 PST
Before I forget... 

Boris: thanks for taking the time to respond.
Comment 3 User image Anne (:annevk) 2008-01-07 03:44:42 PST
If a 404 comes with a text/xml MIME type I'm not sure why responseXML should return null. The only special response code as far as XMLHttpRequest is concerned is 304 and that is called out explicitly.
Comment 4 User image Robert Accettura [:raccettura] 2008-01-07 05:43:39 PST
I don't see a problem parsing 404's.  Maybe it's just my way of thinking about it, but a server should serve up the same content-type for errors as it would for successful responses.  If the server chooses not to, that's not the UA's fault.

304's however are a different argument.  A 304 by definition has no content, making the xml parsing problematic.
Comment 5 User image Anne (:annevk) 2008-01-07 05:47:28 PST
If there is no entity body responseXML returns null. That's covered by the specification.
Comment 6 User image Robert Accettura [:raccettura] 2008-01-07 06:05:10 PST
So defining response entity body as:
The response entity body is the fragment of the entity body received so far (LOADING state) or the complete entity body (DONE state). If there is no entity body the response entity body is "null".


Which I would intperpret as the result being:
req.readyState = 4
req.status = 304
req.responseXML = null

That would mean the parser triggering an xml error on a 304 is a violation of specs.
Comment 7 User image Anne (:annevk) 2008-01-07 06:28:53 PST
Comment 8 User image Kris Maglione [:kmag] 2012-10-05 09:17:07 PDT
*** Bug 720801 has been marked as a duplicate of this bug. ***
Comment 9 User image Hallvord R. M. Steen [:hallvors] 2013-09-20 03:32:31 PDT
I think this is just a special case of bug 521301. If you disagree and think 304 needs more special handling, please re-open.

*** This bug has been marked as a duplicate of bug 521301 ***
Comment 10 User image Boris Zbarsky [:bz] (still a bit busy) 2013-09-20 07:11:12 PDT
I think this is somewhat different: this is talking about the console error, not the responseXML value.  Those are somewhat decoupled.
Comment 11 User image Thomas Wisniewski 2016-09-19 20:57:36 PDT
I'm currently working on suppressing web console "parsing failure" messages on 204 and 304 responses in bug 884693, so marking this a dupe.

*** This bug has been marked as a duplicate of bug 884693 ***

Note You need to log in before you can comment on or make changes to this bug.