XmlHttpRequest parsing of 304 error returns

RESOLVED DUPLICATE of bug 884693

Status

()

Core
XML
RESOLVED DUPLICATE of bug 884693
9 years ago
7 months ago

People

(Reporter: raccettura, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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
request.overrideMimeType('text/plain');

... 

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;
    processResponse(req);
  } else if(req.status == 304){
    // No parsing since no data.
    processResponse(null);
  }
}

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.
(Reporter)

Comment 2

9 years ago
Before I forget... 

Boris: thanks for taking the time to respond.

Comment 3

9 years ago
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.
(Reporter)

Comment 4

9 years ago
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

9 years ago
If there is no entity body responseXML returns null. That's covered by the specification.
(Reporter)

Comment 6

9 years ago
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".

(http://www.w3.org/TR/XMLHttpRequest/#response-entity-body)

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

9 years ago
Yes.
Summary: XmlHttpRequest parsing of non-xml data → XmlHttpRequest parsing of 304 error returns
Version: unspecified → Trunk

Updated

5 years ago
Duplicate of this bug: 720801
I think this is just a special case of bug 521301. If you disagree and think 304 needs more special handling, please re-open.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 521301
I think this is somewhat different: this is talking about the console error, not the responseXML value.  Those are somewhat decoupled.
Status: RESOLVED → REOPENED
Depends on: 521301
Resolution: DUPLICATE → ---

Comment 11

7 months ago
I'm currently working on suppressing web console "parsing failure" messages on 204 and 304 responses in bug 884693, so marking this a dupe.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago7 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 884693
You need to log in before you can comment on or make changes to this bug.