XmlHttpRequest & Opera8.00 - Test for setRequestHeader?

[Matt Kruse]

I'd like to test for Opera8.00's missing setRequestHeader method before
actually instantiating the object. For example, this works in firefox:

if (XMLHttpRequest.prototype.getRequestHeader) { ... }

It causes an error in Opera8.00. In fact, doing
typeof(XMLHttpRequest.prototype) returns 'undefined' in Opera8.00. I'm not
sure how Opera is actually implementing the XMLHttpRequest object, but I
suppose it's not a native object that can be examined? If I instantiate an
object, I can test just fine:

var x = new XMLHttpRequest();
if (x.setRequestHeader) { ... }

But before I get to the point of instantiating, I'd like to detect whether
submitting my POST form is going to work at all, so I can bomb out if it
won't be supported. Is there a better way to test?

Also, while I'm here...

Is there a preferred way to instantiate an XMLHttpRequest object for IE?
I've seen all kinds of different approaches. Some try a long list of ActiveX
components, some just instantiate XMLHTTP, some Microsoft.XMLHTTP, some
Msxml2.XMLHTTP, etc. Many use try/catch which will break older browsers. Is
there a proven method which degrades nicely and will work consistently with
IE?

 

[Richard Cornford]

I'd like to test for Opera8.00's missing setRequestHeader
method before actually instantiating the object. ...

But before I get to the point of instantiating, I'd like to
detect whether submitting my POST form is going to work at
all, ...

<snip>

There is no point trying this as you cannot determine the viability of
XMLHttpRequests on IE without instantiating the object (or at least
trying to, as failure to instantiated is the indicator of
non-viability).

Richard.

 

[Hallvord R. M. Steen]

I'd like to test for Opera8.00's missing setRequestHeader method before
actually instantiating the object. For example, this works in firefox:

if (XMLHttpRequest.prototype.getRequestHeader) { ... }

It causes an error in Opera8.00. In fact, doing
typeof(XMLHttpRequest.prototype) returns 'undefined' in Opera8.00.

Correct, the XMLHttpRequest object does not have a prototype - Opera does
not (yet?) support extending it through the prototype syntax.

Try this approach:

if( ( new XMLHttpRequest() ).setRequestHeader ){
// setRequestHeader is supported
}

Is there a preferred way to instantiate an XMLHttpRequest object for IE?

No idea. The scripts I've seen that seem most thoroughly tested do rely on
a list of identifiers and try...catch, so I'd assume that is the best
approach.

 

[Martin Honnen]

Is there a preferred way to instantiate an XMLHttpRequest object for IE?
I've seen all kinds of different approaches. Some try a long list of ActiveX
components, some just instantiate XMLHTTP, some Microsoft.XMLHTTP, some
Msxml2.XMLHTTP, etc. Many use try/catch which will break older browsers. Is
there a proven method which degrades nicely and will work consistently with
IE?

It depends on what you want to achieve, what features of MSXML you are
looking for. For instance if you are going to load an XML document and
and XSLT stylesheet to perform an XSLT 1.0 transformation then you need
at least MSXML 3 which has the version dependent program id
Msxml2.XMLHTTP.3.0
so in that case it might make sense to try to instantiate that
particular version dependent program id or in case you want to exploit
better XSLT performance in later MSXML versions you might even want to
try to instantiate higher versions to use the highgest version available.

As for try/catch you can use conditional comments to avoid problems with
older browsers.

See also
<http://www.faqts.com/knowledge_base/view.phtml/aid/35742/fid/616>
which tries to be some guidance on the use of programming ids.

 

[Matt Kruse]

It depends on what you want to achieve, what features of MSXML you are
looking for.

I'm actually not looking for MSXML features at all, just XMLHHTP (data will
be JSON).

See also
<http://www.faqts.com/knowledge_base/view.phtml/aid/35742/fid/616>
which tries to be some guidance on the use of programming ids.

I did see this in my pre-post research. This in particular made me wonder:

:Note that from MSXML 4 on there are only version dependent program ids
:so that the earlier version independent program ids are never bound to
:MSXML 4 or 5.

Does the same apply to XMLHTTP? If I just instantiate "Microsoft.XMLHTTP"
will I always get the latest version? Or will it only link to older
versions? I want to always get the latest and greatest that is on the
machine, which would presumably be more efficient and stable and bug-free.
But I also don't want to update my script every time a new version is
released so I can check for it also.

 

[Martin Honnen]

Matt Kruse wrote:

This in particular made me wonder:

:Note that from MSXML 4 on there are only version dependent program ids
:so that the earlier version independent program ids are never bound to
:MSXML 4 or 5.

Does the same apply to XMLHTTP? If I just instantiate "Microsoft.XMLHTTP"
will I always get the latest version? Or will it only link to older
versions? I want to always get the latest and greatest that is on the
machine, which would presumably be more efficient and stable and bug-free.

Microsoft.XMLHTTP is a version independent program id which is never
bound to MSXML 4 or later. MSXML 3 is the last version that can be (and
usually is) installed in so called replace mode (meaning it replaces
earlier versions and binds itself to the version independent ids), if
you want to use MSXML 4 or later you need to use version dependent ids
(e.g. new ActiveXObject('Msxml2.XMLHTTP.4.0') for the XMLHTTP request
object of MSXML 4). So there is no way to use one general version
independent program id and ensure that the latest MSXML version is used,
if you really expect MSXML 4 or later on the client then you have to use
a version dependent program id respectively try to instantiate certain
versions to find the latest installed version.