Xmlhttprequest
The native object of modern browsers
Msxml2.XMLHTTP
Also valid as MSXML2.XMLHTTP.3.0 in accordance with the Knowledge base of MSDN this Activex object introduced with MSXML2, represents today a fallback for versions 5.x and 6.0 of Internet Explorer.
Msxml3.XMLHTTP
It should actually be Msxml2.XMLHTTP.3.0 because, second a comment on the MSDN discussion channel, there is no Progid valid which corresponds to Msxml3.XMLHTTP because the object was somehow "unified" and the specific versioning suffixed (Msxml2.XMLHTTP.3.0, Msxml2.XMLHTTP.6.0...)
Still according to the above MSDN article, this definition is the fallback for versions prior to Internet Explorer 7 as described on MSDN base Knowledge
Microsoft.XMLHTTP
Internet Explorer 5, as if someone still remembers it :p
Finally, an improved version of your code, also coming from the MSDN discussion channel with link above, if the native object does not exist:
if( !window.XMLHttpRequest )
{
window.XMLHttpRequest = function()
{
try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); } catch( e ) { }
try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); } catch( e ) { }
try { return new ActiveXObject("Msxml2.XMLHTTP"); } catch( e ) { }
try { return new ActiveXObject("Microsoft.XMLHTTP"); } catch( e ) { }
throw "Could not create XMLHTTP object.";
}
}
That’s because according this article in one of MSDN’s bloogs, the approach in which you list all possible objects and then iterate through the collection and instance to the one with the largest Progid, is wrong. And the reasons given here translated are:
Compatibility - We do our best to maintain compatibility throughout MSXML versions, but early versions such as MSXML 3 and MSXML 4 have been implemented in the "Wild West" of the emergence of XML and much has been learned and improved over that time.
Additionally, MSXML 5 for Microsoft Office Apications was created with a specific focus for Microsoft Office scenarios. Sometimes for design or implementation reasons it is necessary to change things that affect the behavior of MSXML between its different versions
By iterating a collection of MSXML objects you open your Application to the potential risk of "bumping into" one of these differences unexpectedly.
Robuztez - We cannot fix all the bugs found in each of the many versions of MSXML and therefore we have created MSXML6 (latest[1]) and MSXML3 (the most widely developed[1]), which received large investments.
Costs of the Tests - The more versions of MSXML your Application potentially depends on means the more versions you should test it on before interfacing it with your clients.
[1] Translator’s Note: Until the date of the article in 2006