Instantiating XHR (Code Worth Recommending Project)

P

Peter Michaux

Instantiating an XMLHttpRequest object in Internet Explorer is a bit
confusing. I have seen all of the following in various places and I
have seen the string argument with various captializations.

new ActiveXObject('Microsoft.XMLHttp')
new ActiveXObject('MSXML2.XMLHttp')
new ActiveXObject('MSXML2.XMLHttp.3.0')
new ActiveXObject('MSXML2.XMLHttp.4.0')
new ActiveXObject('MSXML2.XMLHttp.5.0')
new ActiveXObject('MSXML2.XMLHttp.6.0')

It seems as though ActiveXObject is case insensitive to its argument.
I have looked but cannot find documentation to support this. Does
anyone know where Microsoft states this?

Deciding which argument(s) to try is confusing. Even the Microsoft
people don't agree:

From Microsoft's XML team's blog
<URL: http://blogs.msdn.com/xmlteam/archi...ht-version-of-msxml-in-internet-explorer.aspx>

From Microsoft's IE team blog
<URL: http://blogs.msdn.com/ie/archive/2006/01/23/516393.aspx>

What I gather from the above two pages is the following.

"Microsoft.XMLHTTP" is for legacy. This may be implemented in MSXML3
as a synonym for legacy support. A computer that only has MSXML3
installed will still function. Knowing if the two are synonyms is
important.

"Msxml2.XMLHTTP.2.0" should be avoided???

"Msxml2.XMLHTTP.3.0" and "Msxml2.XMLHTTP" may be synonymous and are on
all OS from fully patched Win2k SP4 and up

"Msxml2.XMLHTTP.4.0" was never released with an OS and completely
superseeded by MSXML6

"Msxml2.XMLHTTP.5.0" is for use with Microsoft Office only

"Msxml2.XMLHTTP.6.0" is the new standard that may have some advantages
over older versions but maybe not for the XHR object.

Testing that a page that uses an ActiveX XHR object requires testing
on a variety of computers that have certain dll files corresponding to
the arguments tried when instantiating the ActiveXObject. Keeping the
number of arguments tried to a minimum reduces the number of dll files
that need to be tested. To determine which dlls are installed on the
computer look in System32 folder to find files like "msxml3.dll"

The IE blog recommends using Microsoft.XMLHTTP and the XML team blog
recommends using MSXML2.XMLHttp.3.0. My guess is the XML team is not
thinking like a browser script programmer that is worried about
backwards compatability.

A page about this by Martin Honnen

<URL: http://www.faqts.com/knowledge_base/view.phtml/aid/35742>


--------------------------------------

The following function would be the maximum function that could be
used if MSXML 4 and 5 should not be used. It doesn't test the
abilities of the XHR but just sets a function that is capable of
instantiating an XHR. A function that will use XHR objects must
determine if XHR in the browser has the necessary set of abilities for
the function. '

var createXMLHttpRequest = (function() {
var xhr,
i,
fs = [// for legacy eg. IE 5
function() {
return new ActiveXObject("Microsoft.XMLHTTP");
},
// for fully patched Win2k SP4 and up
// next line may be useless and just a synonym for
// the Microsoft.XMLHTTP factory above
function() {
return new ActiveXObject("Msxml2.XMLHTTP.3.0");
},
// IE 6 users that have updated their msxml dll files.
function() {
return new ActiveXObject("Msxml2.XMLHTTP.6.0");
},
// IE7, Safari, Mozilla, Opera, etc
function() {
return new XMLHttpRequest();
}];

// Loop through the possible factories to try and find one that
// can instantiate an XMLHttpRequest object that works.
for (i=fs.length; i--; ) {
try {
if (fs()) {
return fs;
}
}
catch (e) {}
}

})();

---------------

The minimum function would be the following

var createXMLHttpRequest = (function() {
var xhr,
i,
fs = [// IE 6-
function() {
return new ActiveXObject("Microsoft.XMLHTTP");
},
// IE7, Safari, Mozilla, Opera, etc
function() {
return new XMLHttpRequest();
}];

// Loop through the possible factories to try and find one that
// can instantiate an XMLHttpRequest object that works.
for (i=fs.length; i--; ) {
try {
if (fs()) {
return fs;
}
}
catch (e) {}
}

})();

Of course both of the above can be included in the repository. What
I'd like to know is if there is any advantage at all by using the
longer version.
 
V

VK

Instantiating an XMLHttpRequest object in Internet Explorer is a bit
confusing.

The confusion originates from a highly confused - yet currently
standard de facto - usage of IXMLHTTPRequest (that became
XmlHttpRequest on others, "ajaxoid" any further in this post for
brevity if referring in general for all browsers). IXMLHTTPRequest is
an iternal XML tool used in Microsoft solutions for data binding. In
the most simple way one has a DOM node (div, table cell, table -
whatever) client-side and static or dynamic data source server-side.
By using data binding commands/attributes one creates binding between
DOM nodes and a data fields in the said source. After all bindings are
set, all you have to do is to issue new send() requests: the necessary
page updates are going automatically ondataavailable. This very time
and resource effective solution exists since IE4 on Windows platforms.
Alas the adaptation of ajaxoid is gone in a completely different
direction. Basically after the "discover" it was used as some "XXIst
century cool and advanced" replacement for the age old form
target="HiddenFrame" trick. So developers have chosen to use ajaxoid
as a manually driven transport for data retrieval from the server with
further manual data handling and page update. This btw answers the
frequent question "what are the advantages of ajaxoid over hidden
frame submission?". The answer is: "In the spelled above misuse there
are not any. Ajaxoid is even much lesser functional than hidden frame
submission because it cannot handle input type="file".

How is interested may also read mine and others' post of the year 2005
thread "what's wrong with ajax?":
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/f6ce0a5e95d8bf30

Now coming back to the original question of XMLHTTP versioning. If the
ajaxoid is "standardly misused" as a hidden browser to get textual
data from the server then it is irrelevant what version to use: any
will go. In this case it is better to stick to the universal alias
"Microsoft.XMLHTTP", that covers anything from IE4 till now. If the
ajaxoid is really used for XML data handling then it may be important
to know what XMLHTTP version is available: or not important - it all
depends on what XML features and XPath commands are used. There cannot
be any general suggestions besides two:
1) Check for used XML features and XPath commands availability to know
the lowest supported XMLHTTP version.
2) If fall-back goes up to XMLHTTP 3.0 inclusive and if it's the only
one available on the client - then don't forget to switch the default
language from XSLPattern to XPath. For any older version XPath is by
default.

From the source reliability point of view the linked MSDN blog has
higher value over anything else because it is written by guy(s) who
really making MSXML:
http://blogs.msdn.com/xmlteam/archi...ht-version-of-msxml-in-internet-explorer.aspx

There are more useful info in my discussion with the blog author at
microsoft.public.xml
http://groups.google.com/group/microsoft.public.xml/browse_frm/thread/7772ac2ad016e2bf
 
T

Thomas 'PointedEars' Lahn

VK published another of his (in)famous fairytale stories:
The confusion originates from a highly confused - yet currently standard
de facto - usage of IXMLHTTPRequest (that became XmlHttpRequest on
others,

There is _no_ implementation that provides `XmlHttpRequest'. All non-MS
implementations of IXMLHTTPRequest use the identifier `XMLHttpRequest'.
"ajaxoid" any further in this post for brevity if referring in general
for all browsers). IXMLHTTPRequest is an iternal XML tool used in
Microsoft solutions for data binding. In the most simple way one has a
DOM node (div, table cell, table - whatever) client-side and static or
dynamic data source server-side. By using data binding
commands/attributes one creates binding between DOM nodes and a data
fields in the said source.

Nonsense. IXMLHTTPRequest was first employed in Microsoft Outlook Web
Access for providing Web access to Exchange servers. It had and has nothing
to do with data binding provided by Microsoft ActiveX Data Objects (ADO).

http://en.wikipedia.org/wiki/Ajax_(programming)#History pp.
http://en.wikipedia.org/wiki/ActiveX_Data_Objects pp.
After all bindings are set, all you have to do is to issue new send()
requests: the necessary page updates are going automatically
ondataavailable.

Again, ADO has nothing to do with IXMLHTTPRequest.
This very time and resource effective solution exists since IE4 on
Windows platforms.

It existed before, but Internet Explorer 4 for Windows was the first Web
browser to support that feature.
Alas the adaptation of ajaxoid is gone in a completely different
direction.
ROTFL.

[...]
Now coming back to the original question of XMLHTTP versioning. If the
ajaxoid is "standardly misused" as a hidden browser to get textual data
from the server then it is irrelevant what version to use: any will go.

Wrong, if you try to create an instance of an ActiveX/COM object of a
version that is not installed, an exception will be thrown.
In this case it is better to stick to the universal alias
"Microsoft.XMLHTTP", that covers anything from IE4 till now.

Nonsense. "Microsoft.XMLHTTP" selects the latest available XMLHTTP version
installed on the client system. That object will of course not always
provide the features introduced in possible later versions.

http://www.faqts.com/knowledge_base/view.phtml/aid/35742
If the ajaxoid is really used for XML data handling then it may be important to
know what XMLHTTP version is available: or not important - it all depends
on what XML features and XPath commands are used. There cannot be any
general suggestions besides two: 1) Check for used XML features and XPath
commands availability to know the lowest supported XMLHTTP version.

Nonsense, see below.
2) If fall-back goes up to XMLHTTP 3.0 inclusive

How can a fall*back* go *up* in version numbers?
and if it's the only one available on the client - then don't forget
to switch the default language from XSLPattern to XPath. For any older
version XPath is by default.

Nonsense. XPath support was not introduced in MSXML before version 3.0.

http://msdn2.microsoft.com/en-us/library/ms754523.aspx
From the source reliability point of view the linked MSDN blog has higher
value over anything else because it is written by guy(s) who really
making MSXML:
http://blogs.msdn.com/xmlteam/archi...ht-version-of-msxml-in-internet-explorer.aspx

Why all your telling fairytale stories then?
There are more useful info in my discussion with the blog author at
microsoft.public.xml
http://groups.google.com/group/microsoft.public.xml/browse_frm/thread/7772ac2ad016e2bf

In which your misconceptions were also corrected but you did not take notice
of that at all. Quoting Alex Krawarik [MSFT], to you: "As such, please stop
doling out bad advice." I second that.


PointedEars
 
P

Peter Michaux

The confusion originates from a highly confused - yet currently
standard de facto - usage of IXMLHTTPRequest (that became

[snip]

The Google Groups interface seems to think that Thomas "PointedEars"
Lahn has replied to this post but the body of Thomas' post does not
appear unfortunately.
 
V

VK

The Google Groups interface seems to think that Thomas "PointedEars"
Lahn has replied to this post but the body of Thomas' post does not
appear unfortunately.

Yes, I noticed it as well. I hope that Thomas will not take it as some
nasty VK's conspiracy :)
 
D

David Mark

]snip]
var createXMLHttpRequest = (function() {
var xhr,
i,
fs = [// for legacy eg. IE 5
function() {
return new ActiveXObject("Microsoft.XMLHTTP");
},
// for fully patched Win2k SP4 and up
// next line may be useless and just a synonym for
// the Microsoft.XMLHTTP factory above
function() {
return new ActiveXObject("Msxml2.XMLHTTP.3.0");
},
// IE 6 users that have updated their msxml dll files.
function() {
return new ActiveXObject("Msxml2.XMLHTTP.6.0");
},
// IE7, Safari, Mozilla, Opera, etc
function() {
return new XMLHttpRequest();
}];

// Loop through the possible factories to try and find one that
// can instantiate an XMLHttpRequest object that works.
for (i=fs.length; i--; ) {
try {
if (fs()) {
return fs;
}
}
catch (e) {}
}

})();


This looks right to me. As mentioned, the four unique MS
implementations (three ActiveX) have differences. One is that IE7's
take on XMLHttpRequest does not support the overrideMimeType crutch.
---------------

The minimum function would be the following

var createXMLHttpRequest = (function() {
var xhr,
i,
fs = [// IE 6-
function() {
return new ActiveXObject("Microsoft.XMLHTTP");
},
// IE7, Safari, Mozilla, Opera, etc
function() {
return new XMLHttpRequest();
}];

// Loop through the possible factories to try and find one that
// can instantiate an XMLHttpRequest object that works.
for (i=fs.length; i--; ) {
try {
if (fs()) {
return fs;
}
}
catch (e) {}
}

})();


This should be sufficient for most applications and is less ambiguous.
Of course both of the above can be included in the repository. What
I'd like to know is if there is any advantage at all by using the
longer version.

None that I know of.
 
T

Thomas 'PointedEars' Lahn

Peter said:
The confusion originates from a highly confused - yet currently
standard de facto - usage of IXMLHTTPRequest (that became

[snip]

The Google Groups interface seems to think that Thomas "PointedEars"
Lahn has replied to this post

Which actually happened.
but the body of Thomas' post does not appear unfortunately.

Not using Google's faulty Web interface, unless one temporarily has to,
might be the solution to this problem. Besides the mentioned bug, for
example, your signature is broken; it has to be delimited with "-- "
(followed by CRLF), and it is delimited with "--" (followed by CRLF).


PointedEars
 
V

VK

Not using Google's faulty Web interface, unless one temporarily has to,
might be the solution to this problem.

Or using a descent NNTP server for posting: in my memory this is the
first time ever in Google Groups the title is displayed but no body.
Also my free two free NNTP servers I am using as a reserve one missed
the post completely, other reported the same header w/o body. Someone
is playing hard with message headers I guess (?)

Anyway I have gotten the post over developersdex mirror:
http://www.developersdex.com/asp/message.asp?p=2978&r=6080012

Nothing really interesting to argue with productively but thanks for
correcting the typo: XMLHttpRequest, not "XmlHttpRequest". The object
name is using broken camel-case schema - I guess to stress out on XML.
 
T

Thomas 'PointedEars' Lahn

VK said:
Anyway I have gotten the post over developersdex mirror:
http://www.developersdex.com/asp/message.asp?p=2978&r=6080012

Nothing really interesting to argue with productively

You are a sorry excuse for a participant in a discussion. What I posted is
nothing that you could reasonably debate as I stated the facts (about much
more than just XMLHttpRequest) while you only boldly posted your fantasy
again. At least you could stand corrected for that.
but thanks for correcting the typo: XMLHttpRequest, not "XmlHttpRequest".

You're welcome.
The object name is using broken camel-case schema

1. Reference identifier, not name.

2. If camel-case naming was a requirement defined by a standard, only then
using the word "broken" for different naming would be appropriate.
- I guess to stress out on XML.

Not understood.


PointedEars
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]>, Sun,
16 Dec 2007 14:06:01 said:
Not using Google's faulty Web interface, unless one temporarily has to,
might be the solution to this problem. Besides the mentioned bug, for
example, your signature is broken; it has to be delimited with "-- "
(followed by CRLF), and it is delimited with "--" (followed by CRLF).

Since you evidently do not yourself understand how a signature should be
constructed, as you have repeatedly been told, you are once again
demonstrating your truly obnoxious personality.
 
T

Thomas 'PointedEars' Lahn

Dr said:
[...] Thomas 'PointedEars' Lahn [...] posted:
Not using Google's faulty Web interface, unless one temporarily has to,
might be the solution to this problem. Besides the mentioned bug, for
example, your signature is broken; it has to be delimited with "-- "
(followed by CRLF), and it is delimited with "--" (followed by CRLF).

Since you evidently do not yourself understand how a signature should be
constructed, as you have repeatedly been told, you are once again
demonstrating your truly obnoxious personality.

I have explained what is technically required for a signature as it is
understood for Usenet messages and by properly working newsreader software,
which is not met here. Anything else follows merely from your ongoing
misinterpretation of recommendations and even Internet drafts as standards:

As long as I have a line in my posting containing only "-- " (+CLRF), what
follows qualifies as a signature; it is a signature that follows universally
accepted Usenet guidelines if it is not more than four lines. What is above
that delimiter is _not_ part of the signature, and as such it is only by its
format, and not by its content, subject of any (quasi-)standard. (And that
format as defined in RFC1036 was obeyed.)

To be precise, if I do not want to make my (nick)name-signature part of the
signature as that is technically understood (for example, in order to keep
the signature short!), I am absolutely free to do so, and removing it is for
readers not any harder than snipping any other part of any other posting.

And if I do not want to put contact information in my signature but a
randomly selected text instead, like evidently a number of other Usenet
participants, many of them being regulars, do, I am absolutely free to do
so, even though I would not follow the evidently rather outdated
corresponding recommendation in RFC1855, then.

If you want to bother someone about their postings not conforming to
(quasi-)standards, why don't you start with bothering the large number of
incompetent anti-social people who help to break the medium as a means of
building a social network by using non-existing e-mail addresses in address
headers, a clear violation of RFC1036 and STD11 (obsoleted by RFC2822)?


EOD

PointedEars
 
P

Peter Michaux

Or using a descent NNTP server for posting: in my memory this is the
first time ever in Google Groups the title is displayed but no body.
Also my free two free NNTP servers I am using as a reserve one missed
the post completely, other reported the same header w/o body. Someone
is playing hard with message headers I guess (?)

Anyway I have gotten the post over developersdex mirror:http://www.developersdex.com/asp/message.asp?p=2978&r=6080012

Thanks.

Thomas wrote that "'Microsoft.XMLHTTP' selects the latest available
XMLHTTP version
installed on the client system." and I believe that is not true based
on things I've been reading lately. Can Thomas' claim be
substantiated?
 
T

Thomas 'PointedEars' Lahn

Peter said:
Thomas wrote that "'Microsoft.XMLHTTP' selects the latest available
XMLHTTP version installed on the client system." and I believe that
is not true based on things I've been reading lately.

Without you naming then things you are referring to, I may as well
say I didn't believe you either. That's a great style of discussion,
isn't it?
Can Thomas' claim be substantiated?

Create the object, check the properties it provides and cross-check
with the version information for that property in the MSDN Library.


PointedEars
 
P

Peter Michaux

Without you naming then things you are referring to, I may as well
say I didn't believe you either. That's a great style of discussion,
isn't it?

It isn't optimal.

Create the object, check the properties it provides and cross-check
with the version information for that property in the MSDN Library.

Is there Microsoft documentation to substantiate your claim? I have
not seen any and I have been reading about this on the Microsoft site.
The only thing I've seen is in the XML blog post link I posted in the
first post of this thread. It says that if MSXML3.dll (or whatever it
is called) is installed then Microsoft.XMLHTTP will use it. I have not
seen that if MSXML6.dll (or whatever it is called) is installed that
Microsoft.XMLHTTP should be used.
 
P

Peter Michaux

Peter Michaux said the following on 12/16/2007 7:49 PM:


Can you give URL's to what you have been reading lately?

The only links I still have are the ones I posted
Yes. From your own URL in fact:

<quote cite="http://www.faqts.com/knowledge_base/view.phtml/aid/35742>

The version independent program id for an XML HTTP request object is
Microsoft.XMLHTTP
thus
var httpRequest = new ActiveXObject('Microsoft.XMLHTTP');
creates an XML HTTP request object in IE 5 or later.

Which actual MSXML version such a program id is bound to depends on the
MSXML version(s) installed and even on the mode (side-by-side or replace
mode) a version is installed in.
</quote>

Until I see something that proves Martin wrong, I believe what he writes
- unconditionally.

<quote site="http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-
the-right-version-of-msxml-in-internet-explorer.aspx">
#
Version Independent ProgIDs - There's a lot of confusion around the
"version-independent" ProgID for MSXML. The version-independent
ProgID is always bound to MSXML 3 (a lot of people think it picks up
the latest MSXML that is on the box). This means the version
independent ProgID and the "3.0" ProgIDs will return the same object.
For example both statements in the following code will return an MSXML
3 DOMDocument:

var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.3.0')

and

var xmlDOM = new ActiveXObject('Msxml2.DOMDocument')

</quote>

Confusing, eh?
 
P

Peter Michaux

Peter Michaux said the following on 12/16/2007 10:20 PM:







I read that part as well. It is referring to two different things
though. DOMDocument versus XMLHTTP. Martin could come closer to telling
you the difference in the two than I can.

The DOMDocument part is just a "for example". I think the statement is
general and does apply here.

I know that Martin certainly knows his stuff but the XML blog does
seem to be making a different statement here.
 
M

Martin Honnen

Randy said:
Given the current state of the quality of MS blog's and MSDN
documentation, and Martin's track record, I believe Martin. Would be
nice to see a test to see which one it uses though to make sure.

Msxml2.DOMDocument respectively Msxml2.XMLHTTP can be bound to MSXML 3
or earlier but not to later versions. The same holds for
Microsoft.XMLDOM and Microsoft.XMLHTTP.

So to create a DOMDocument or XMLHTTP for MSXML 4, 5, or 6 you need to
use version specific program ids meaning you need Msxml2.DOMDocument.4.0
respectively Msxml2.XMLHTTP.4.0 for MSXML 4, Msxml2.DOMDocument.5.0
respectively Msxml2.XMLHTTP.5.0 for MSXML 5, and Msxml2.DOMDocument.6.0
respectively Msxml2.XMLHTTP.6.0 for MSXML 6.

The XML team blog is based on supported MS OS versions, those have at
least IE 6 or 7 and that way MSXML 3 around meaning
Msxml2.DOMDocument.3.0 respectively Msxml2.XMLHTTP.3.0 can be assumed as
being around and are therefore suggested as the common base.

If you want to write code for IE 5 or 5.5 then you are in area the XML
team blog does not cover as those versions respectively OS with those
version are no longer supported by MS. For those browsers you might want
to resort to Msxml2.DOMDocument respectively Msxml2.XMLHTTP or even
Microsoft.XMLDOM respectively Microsoft.XMLHTTP.
 
D

Dr J R Stockton

In comp.lang.javascript message said:
Thomas 'PointedEars' Lahn said the following on 12/16/2007 7:44 PM:

Your problem is you don't comprehend what constitutes a "signature".

I don't think he can be that stupid. It is merely a manifestation of
his defective personality. He must have a syndrome akin to Tourette's,
but with a different manifestation.
 
P

Peter Michaux

Msxml2.DOMDocument respectively Msxml2.XMLHTTP can be bound to MSXML 3
or earlier but not to later versions. The same holds for
Microsoft.XMLDOM and Microsoft.XMLHTTP.

This is just what I have been looking for. Thank you!

Do you have a link to a bit of Microsoft documentation that states the
above?

Thanks again.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top