XmlHttpRequest (XHR) often does a lot of the heavy lifting with converting text into an XML document when performing a resource request, but sometimes requires a little bit of a boost. It will only convert the document to an XML node structure if the MIME type from the server indicate it’s an xml-structured document. This can be anything from “text/xml” to more custom formats like “application/ttml+xml”. This all requires the MIME type to be registered on the server for the file extension, like so. If it isn’t, too bad, the file is coming back as “text/plain”, and the browser doesn’t convert it to XML. I hope the calling application wasn’t requiring the user to do this, because if so, the app just broke.
What does this mean for software developers? Is it fair to expect every user to have to update mime.types or .htaccess so they can use the application? Even if it weren’t for the technological burden it places on the user, it’s just plain unfair to ask 100 people to do what you could just do yourself. So XHR allows you to overrideMimeType for the expected result, allowing for browsers to treat xml documents as xml, even if they come back as text/plain. Which would be great in a world of universal browser support.
For example, IE 6 and below didn’t use XHR, and relied on a different mechanism (ActiveX) to perform requests from JavaScript. With the introduction of it in IE7, there still wasn’t support for mime type overriding. Which meant a convoluted process of indicating the browser should convert it when XHR.overrideMimeType was supported, and converting it manually when it wasn’t. This is great, but still brings us back to placing the burden of the user to configure what the developer was too lazy to do explicitly.
After some digging into why some code was crashing recently, I realized this, and decided a good solution would be to manually convert the XHR result to an xml node structure if it wasn’t already. In typical circumstances, this would be the case only because the mime type was wrong. In atypical cases, the document itself is invalid XML, at which point the fix is out of the developer’s hands and responsibility shifts to the creator of the document. 95% of the time failures in situation occur though, it’ could’ve been avoided by defensive coding and re-parsing the xml content if it wasn’t automatically by the browser.
So I made a utility function to do this. Most browsers already have the tools, all it took was creating a cross-browser wrapper for them. Grab it from GitHub, or see it below:
// Convert a string to XML Node Structure
// Returns null on failure
function textToXML ( text ) {
try {
var xml = null;
if ( window.DOMParser ) {
var parser = new DOMParser();
xml = parser.parseFromString( text, "text/xml" );
var found = xml.getElementsByTagName( "parsererror" );
if ( !found || !found.length || !found[ 0 ].childNodes.length ) {
return xml;
}
return null;
} else {
xml = new ActiveXObject( "Microsoft.XMLDOM" );
xml.async = false;
xml.loadXML( text );
return xml;
}
} catch ( e ) {
// suppress
}
}

Leave a Reply