Closed Bug 411060 Opened 17 years ago Closed 8 years ago

XmlHttpRequest parsing of 304 error returns


(Core :: XML, defect)

Not set





(Reporter: raccettura, Unassigned)



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.
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.
Before I forget... 

Boris: thanks for taking the time to respond.
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.
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.
If there is no entity body responseXML returns null. That's covered by the specification.
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.
Summary: XmlHttpRequest parsing of non-xml data → XmlHttpRequest parsing of 304 error returns
Version: unspecified → Trunk
I think this is just a special case of bug 521301. If you disagree and think 304 needs more special handling, please re-open.
Closed: 11 years ago
Resolution: --- → DUPLICATE
I think this is somewhat different: this is talking about the console error, not the responseXML value.  Those are somewhat decoupled.
Depends on: 521301
Resolution: DUPLICATE → ---
I'm currently working on suppressing web console "parsing failure" messages on 204 and 304 responses in bug 884693, so marking this a dupe.
Closed: 11 years ago8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.