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


Description 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 Boris Zbarsky [:bz] 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 Robert Accettura [:raccettura] 2008-01-06 19:28:33 PST
Before I forget... 

Boris: thanks for taking the time to respond.
Comment 3 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 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 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 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 Anne (:annevk) 2008-01-07 06:28:53 PST
Comment 8 Kris Maglione [:kmag] 2012-10-05 09:17:07 PDT
*** Bug 720801 has been marked as a duplicate of this bug. ***
Comment 9 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 Boris Zbarsky [:bz] 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.

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