Client Side Web Development

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

Fotiman — Fri, 13 Nov 2009 16:35:06 GMT

Deleted duplicate post.

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

Fotiman — Fri, 13 Nov 2009 16:34:06 GMT

The arguments about Microsoft dropping support for the Microsoft namespace in the future are irrelevant. That has already happened. You can not get an MSXML2.XMLHTTP.6.0 object using the Microsoft.XMLHTTP namespace (and nor can you get an MSXML2.XMLHTTP.6.0 object using the MSXML2.XMLHTTP namespace only).

If you want to support IE5, IE5.5, and IE6 you NEED to use Microsoft.XMLHTTP.

If you want to support only IE6 (and explicitly NOT support IE5 and IE5.5), then you should include MSXML2.XMLHTTP.

There is no logical reason to check BOTH MSXML2.XMLHTTP and Microsoft.XMLHTTP, unless you intend to identify (perhaps via log messages) that the user may be using an unsupported implementation. For example, if MSXML2.XMLHTTP does not work, but Microsoft.XMLHTTP does work, then you know the client is IE5 or IE5.5 and might be at higher risk for problems. If, however, you are not bothering to make this distinction, then it is pointless to check for both.

With that said, I believe the best approach is to check for MSXML2.XMLHTTP.6.0, then Microsoft.XMLHTTP (if you want to support the widest range of IE browsers). In this case, if MSXML2.XMLHTTP.6.0 is not available, then Microsoft.XMLHTTP will pick up the next available version from version 3.0 down.

If you only want to support browsers back to IE6, then check for MSXML2.XMLHTTP.6.0, then MSXML2.XMLHTTP. In this case, if MSXML2.XMLHTTP.6.0 is not available, then MSXMLHTTP will pick up the next available version from version 3.0 down (excluding old IE5/5.5 installations).

If you only want to support browsers back to IE6 and only using 6.0 or 3.0 (and nothing older), then check for MSXML2.XMLHTTP.6.0, then MSXML2.XMLHTTP.3.0. This will not match older versions that might be running 2.6 or earlier.

Reference:

http://support.microsoft.com/kb/269238

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

Wukfit — Thu, 29 Jan 2009 11:06:20 GMT

Your right - I don't think using the deprecated namespace is the right way to go - also the code from Dojo above doesn't test for the lastest version (MSXML2.XMLHTTP.6.0).

I use the following code (as per M$ recommendation):

        var tr = !!window.clientInformation,
	progids = ['MSXML2.XMLHTTP.6.0', 'MSXML2.XMLHTTP.3.0', 'Microsoft.XMLHTTP'],
	sProgid = null;
	
	// Wrapper for IE's ActiveObject
	if (tr && !window.XMLHttpRequest) {
		// Returns null if the ActiveX Object can't be created
		window.XMLHttpRequest = function () {
			// Holds a ref to the ActiveXObject or null...
			var xhr = null,
			i = 0;
	
			/* 
			 * Try version 6 first, (the most recent version as of March 2008),
			 * then version 3 (Win2k+) - these two versions are the only ones
			 * offically supported by Microsoft.
			 * 
			 * If these fail fallback to any available version, however,
			 * do we want to do this as we are unable to test this scenario?
			 * 
			 * 6.0 Shipped from Nov 2005 - "in the box" with Vista
			 * 3.0 Most widely deployed - available on W2k+
			 * 
			 * @see http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-in-internet-explorer.aspx
			 */
			if (sProgid) {
				xhr = new window.ActiveXObject(sProgid);
			} else {
				for (; i < progids.length; i += 1) {
					try {
						xhr = new window.ActiveXObject(progids[i]);
						sProgid = progids[i];
						break;
					} catch (e) {
						// Consume...
					}
				}
			}
			
			return (xhr || null);
		};
	}

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

Nath-22 — Wed, 28 Jan 2009 22:49:53 GMT

That's true, think of it instead as "future revisions of MSXML2 may not support the Microsoft namespace".

Maybe the reason they do it, is simply because MSXML2.XmlHttp is the preferred namespace, so they test for that first, however if your browser/COM object whatever you want to call it, doesn't support the MSXML2.XmlHttp namespace, use the Microsoft.XmlHttp namespace instead.

You shouldn't favour/encourage the use of a deprecated method, regardless of whether or not you think it works better or makes more sense (I am guilty of this by using COMPUTE in my T-SQL 2005 queries).

I think you are also partly right with your lack of documentation theory; people may have seen it used in what examples they could find supplied by Microsoft and implemented the same or similar code in their own toolkit, without actually knowing why it was used in the first place.

My thoughts were on the original reason behind it, or, "Why would you want to test for both?"and not "I did it because I saw somebody else do it."

Anyway, you're right, we'll probably never know the real reason without hearing from someone who knows first hand.

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

Wukfit — Wed, 28 Jan 2009 09:23:21 GMT

@Nath-22 Remember MSXML is not tied to a particular browser version and can be updated independantly.

I still think it's lack of good documentation - I can find no evidence that say, DOJO (for instance) is doing anything special with Msxml2.XMLHTTP.4.0 -- unless someone from Dojo (or any of the other js toolkits) wants to comment?

Latest Version (1.2.3)

		// These are in order of decreasing likelihood; this will change in time.
		d._XMLHTTP_PROGIDS = ['Msxml2.XMLHTTP', 'Microsoft.XMLHTTP', 'Msxml2.XMLHTTP.4.0'];

		d._xhrObj = function(){
			// summary: 
			//		does the work of portably generating a new XMLHTTPRequest
			//		object.
			var http = null;
			var last_e = null;
			if(!dojo.isIE || !dojo.config.ieForceActiveXXhr){
				try{ http = new XMLHttpRequest(); }catch(e){}
			}
			if(!http){
				for(var i=0; i<3; ++i){
					var progid = d._XMLHTTP_PROGIDS[i];
					try{
						http = new ActiveXObject(progid);
					}catch(e){
						last_e = e;
					}

					if(http){
						d._XMLHTTP_PROGIDS = [progid];  // so faster next time
						break;
					}
				}
			}

			if(!http){
				throw new Error("XMLHTTP not available: "+last_e);
			}

			return http; // XMLHTTPRequest instance
		}

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

Nath-22 — Wed, 28 Jan 2009 06:12:16 GMT

Hi All, I know this topic is really, REALLY old and everyone has put their two cents in by now, but here's mine:

Think of it as "forward compatibility", I think it has been touched on previously: there's no telling if/when they will completely drop support for the deprecated namespace (that's Microsoft.XmlHttp) in favor of the newer one (MSXML2.XmlHttp).

Also, as previously mentioned, older browsers will NOT support the newer namespace. Future browsers may not support Microsoft.XmlHttp, and older browsers won't support MXML2.XmlHttp. Seeings as either namespace will do, they test for both.

Makes sense to me, anyhow.

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

Wukfit — Fri, 07 Nov 2008 10:25:13 GMT

Hi there webjose,

Just goes to show how crap/confusing MS documentaion is - posting to a 2yr old thread!

I think the original question was more of a why do 'all' the Ajax Libraries test for MSXML2.XMLHttp.3.0, Microsoft.XMLHTTP, MSXML2.XMLHTTP when Microsoft.XMLHTTP will suffice?

I stand by my original answer - lack of good documentation from MS.

But the bigger question to ask is "is this really relevant any more?" - Do you still want to support outdated web browsers for this type of functionality? I know most business will be using at least win2k, probably XP/2003 sure there will be a few IE 5 users out there but looking at the logs of a public facing (non-technical) website I look after, in the last year there was only one visitor using IE5...

E.g.

Prototype:

1      getTransport: function() {
2        return Try.these(
3          function() {return new XMLHttpRequest()},
4          function() {return new ActiveXObject('Msxml2.XMLHTTP')},
5          function() {return new ActiveXObject('Microsoft.XMLHTTP')}
6        ) || false;
7      },

DOJO

"Msxml2.XMLHTTP","Microsoft.XMLHTTP","Msxml2.XMLHTTP.4.0"

YUI

_msxml_progid:[
'Microsoft.XMLHTTP',
'MSXML2.XMLHTTP.3.0',
'MSXML2.XMLHTTP'
],

EXT

activeX:[
        'MSXML2.XMLHTTP.3.0',
        'MSXML2.XMLHTTP',
        'Microsoft.XMLHTTP'
        ]

JQuery

var xhr = window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();

IMHO JQuery has the correct approach - as I doubt very much any of the libs are taking into account the "differences between the two objects...the older one only supported UTF-8" - MS has no documentaion that I could find on older versions...

Cheers!

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

webJose — Fri, 07 Nov 2008 03:05:04 GMT

Ok, old topic, I know, but I think I have the definitive answer to this question. Here I go.

Microsoft.XmlHttp is the ProgID of the XMLHTTPRequest object found in msxml.dll, while MSXML2.XmlHttp is found in msxml2.dll. In Windows XP, you can find both DLLs; in Windows Vista only msxml2.dll is found. If you only have msxml.dll, then Microsoft.XmlHttp is your only way to go; if you have the newer version, its installer redirected Microsoft.XmlHttp to the newer MSXML2.XmlHttp object found in mxml2.dll, resulting in identical objects.

Why do you see that code is tested for both? Compatibility. I don't know the differences between the two objects, but someone mentioned that the older one only supported UTF-8, so on older or outdated systems where only msxml.dll exists, your code might break if it is not accounting for the shortcomings of using the older version.

There! (I hope, haha)

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

Julien de Prabere — Mon, 19 May 2008 21:04:13 GMT

On IE6, Microsoft.XMLHTTP seems not to take care at charset and work only with utf-8 encoded responses, while Msxml2.XMLHTTP, like XMLHttpRequest on other browsers,
respect the charset if it's done (for exemple with an header("Content-Type: text/html; charset=ISO-8859-1"); in PHP) !

It's very important to use pages on other code than utf-8 wich are very usefull with actual PHP...

Julien de Prabère (with an accent please !)

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

A1ien51 — Fri, 17 Aug 2007 14:56:47 GMT

Wukfit:

@eric Hi Eric I just wanted to clarify something with you, are you saying that legacy browser support (e.g. IE 5.x) requires the use of both MSXML2.XMLHTTP and Microsoft.XMLHTTP?

Cheers,
Wukfit

Only Microsoft.XMLHTTP is needed and is what I do now.

A good filter would be to use MSXML2 if you do not want the older browsers!

Now in the future browsers, if MS dumps the Microsoft namespace in IE8+, would we need to use the MSXML2 if we expect our site to be along that long? LOL

Eric

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

Wukfit — Fri, 17 Aug 2007 14:07:40 GMT

@eric Hi Eric I just wanted to clarify something with you, are you saying that legacy browser support (e.g. IE 5.x) requires the use of both MSXML2.XMLHTTP and Microsoft.XMLHTTP?

Cheers,
Wukfit

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

A1ien51 — Fri, 17 Aug 2007 13:27:09 GMT

The only thing I tried to say in my post is the only difference between MSXML2.XmlHttp and Microsoft.XmlHttp is nothing unless you are using an old machine with IE5.x. So using MSXML2.XmlHttp and Microsoft.XmlHttp in the same detecttion is like doing if(apple=="red"){} else if(apple=="red"){}. If I remember correctly that was the whole basis for this discussion.

The only reason I bring up the fact why you could not just use MSXML2.XmlHttp is the fact that there are browsers that do not support it that are out in the wild. If we were talking about a serverside framework, we would not be talking about that because once you upgrade, you get the latest and greatest, and you forget that the outdated namespaces do not exist. I wish that was the case with JavaScript!

What I tell people is this:
If you want to just use the generic ids all you have to test for is the Native Imp and Microsoft.XMLHTTP. [Microsoft.XmlHttp here is the catch all - uses the browser default version]
If you want to specify versions pick out Native Imp., 6, 3, and Microsoft.XMLHTTP. [Microsoft.XMLHTTP is used here as a catch all if someone is running IE5.X and you care about supporting it.]

Why is specifing versions bad?
Because you have to change your code in the future when MS releases a new version!

Why is specifing versions good?
If you are using just responseText and repsonseXML, there is nothing good about it. It you are using other features built into it, than it is good since you can work around known issues.

Why would people use both?
Lack of good documentation, people wanting to use the new namespace instead of the outdated namespace, and old browser support while wanting to use the new namespace. I lean towards lack of documentation like Wukfit said above. I know when I wrote AIA I had trouble finding decent information on it. Playing with my virtual machines with old versions of IE is where I noticed why Microsoft.XmlHttp was needed hence why it was added it with MSXML2.XmlHttp since with testing I knew it worked with IE6.

Eric

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

Wukfit — Fri, 17 Aug 2007 09:44:13 GMT

I wasn't implying that you were a beginner I've no idea what the level of knowledge/experience is of people posting to this forum - so please don't take offence.

OK Just to back up my reasoning for why AJAX frameworks test for multiple versions of the progid...

This snippet is taken from a recent version of the YUI (Yahoo) Library:

YAHOO.util.Connect =
{

/**
* @description Array of MSFT ActiveX ids for XMLHttpRequest.
* @property _msxml_progid
* @private
* @static
* @type array
*/_msxml_progid:['MSXML2.XMLHTTP.3.0', 'MSXML2.XMLHTTP', 'Microsoft.XMLHTTP'],

and...

catch(e) {
for(var i=0; i<this._msxml_progid.length; ++i){
try{

// Instantiates XMLHttpRequest for IE and assign to http.
http = new ActiveXObject(this._msxml_progid[i]);

// Object literal with conn and tId properties
obj = { conn:http, tId:transactionId };

break;

} catch(e){}

}

}... etc

Also from DOJO...

dojo.hostenv._XMLHTTP_PROGIDS = ["Msxml2.XMLHTTP", "Microsoft.XMLHTTP", "Msxml2.XMLHTTP.4.0"]; etc, etc,.

I agree with you in that Eric is wrong - as it stands to instantiate an MSXML to MSXML3 XHR object you only need to use the Microsoft.XMLHTTP progid (the danger is you don't necessarily know which one got created - there might be bugs in the earlier versions)

Is it possible that legacy support for the Microsoft namespace will be dropped in future versions of Internet Explorer/MSXML?

Like I said I believe it's lack of knowledge that is directly related to the considerable lack of (usable) documentation from Microsoft on what the best practises are - I was not saying that creators of these frameworks were "stupid" only that there was little or no documentation/best practises for them to follow.

[EDIT] Incidentally the younger Ajax libraries like JQuery and MooTools only test against/use the Microsoft.XMHTTP progid

Cheers,
Wukfit

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

AGS777 — Fri, 17 Aug 2007 06:46:00 GMT

Eric,

You didn't miss the topic, but, sorry, I don't see logic in your answer.

Of course client machine can have old version of MSXML. But in all the cases Microsoft.XmlHttp is enough to test.

For older systems - it is the only variant, for systems supporting MSXML2 - both MSXML2.XmlHttp and Microsoft.XmlHttp instantiate the same instance of XMLHttp object and the maximum version is MSXML2.XmlHttp.3.0.

So the question WAS AND IS "why to test BOTH?".

Well, you almost convinced me that I am a complete idiot and cannot formulate simple questions correctly (or, I know it for sure, my English is terrible).

But please, I am working with the technology long enough. There is no need for lengthy explanations. I was curious about specific question.

And if the question seems very simple it doesn't necessarily mean that it IS and an author of the question is a beginner.

So once again: name of the thread is "Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs".

IT IS NOT "Difference between various versions of MSXML libarary".

Best regards,

Alexei

Re: Difference between MSXML2.XmlHttp and Microsoft.XmlHttp ProgIDs

A1ien51 — Thu, 16 Aug 2007 23:26:52 GMT

Here is the answer: They are trying to support Win98 with IE5.x! Well I doubt they really are, but that is what it comes down too.

Not sure if this link [http://support.microsoft.com/kb/269238] was ever post above. I did not see it unless I missed it. The link shows all the versions, info about them, browser support, how you got it, etc.

Now why would you use the Microsoft namespace in the detection? When I worked at a website where mom and pops would come to with there old machines, there was an a lot of people coming in with window 98 machines with IE5.5. I was surprised at the numbers and wondered what version of AOL they were running!!! So if you need to support IE5.5 and under that are not upgraded to the latest and greatest, Microsoft.XmlHttp is needed since it lacks the MSXML2 namespace. There are a bunch of JavaScript version issues with running IE5.X so I am sure most code now a days would fail anyay so supporting Microsoft.XmlHttp is rather a waste of time! I rember the fun with IE5.5 to IE6 with new features added to the arrays! Using Array.prototype fixed all of those wonderful holes! I highly doubt anyone is really doing that anymore.

As mention already in this thread, the Microsoft.XmlHttp means the same thing as MSXML2.XmlHttp where MSXML2.XmlHttp is supported. The only reason why Microsoft did this was to support backwards capability when they changed the namespace. They still do it today since we still visit websites from back in the 1995-1998 era! Seeing Microsoft.XmlHttp is sort of like seeing code looking at document.layers, document.all, and blink tags. Someone still wants to support Netscape4.x, just incase there is that one usr reliving the good ole days of browser wars. "640K ought to be enough for anybody."

Personally I specify the 3 and 6, but when I want to have fun in a demo, I start up my virtaul machine with Windows98se and IE5.0 and show people that it has been around for a long time. :) Hopefully in the future we can get away from the ActiveX for good once the IE6 is put to its grave! I been seeing numbers of IE6 drop on website status and moving to IE7. Too bad in IE7, native support can be disabled!

Man I almost forgot about this topic. LOL, maybe I missed the point again for the 100th time.

Eric