Closed
Bug 411060
Opened 17 years ago
Closed 8 years ago
XmlHttpRequest parsing of 304 error returns
Categories
(Core :: XML, defect)
Core
XML
Tracking
()
RESOLVED
DUPLICATE
of bug 884693
People
(Reporter: raccettura, Unassigned)
References
Details
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.
Comment 1•17 years ago
|
||
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•17 years ago
|
||
Before I forget... Boris: thanks for taking the time to respond.
Comment 3•17 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•17 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•17 years ago
|
||
If there is no entity body responseXML returns null. That's covered by the specification.
Reporter | ||
Comment 6•17 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•17 years ago
|
||
Yes.
Updated•17 years ago
|
Summary: XmlHttpRequest parsing of non-xml data → XmlHttpRequest parsing of 304 error returns
Updated•16 years ago
|
Version: unspecified → Trunk
Comment 9•11 years ago
|
||
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
Closed: 11 years ago
Resolution: --- → DUPLICATE
Comment 10•11 years ago
|
||
I think this is somewhat different: this is talking about the console error, not the responseXML value. Those are somewhat decoupled.
Comment 11•8 years 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
Closed: 11 years ago → 8 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•