11-03-2004, 11:29 PM
I am receiving the following JS error message when trying to get the response text from the responseText property of the XMLHTTP ActiveXObject...
System error: -1072896658
I have not experienced this problem until my company upgraded us to IE6. In IE5.5, this worked (and is working) fine.
Here is my code...
var objHTTP = new ActiveXObject("Microsoft.XMLHTTP");
var wURL = "http://peoplelkp.domain.com/peoplelkp/PDLookupService"
var origHTML = objHTTP.responseText;
It is on the last line that the Script Deubugger throws the above error. I have tried re-registering the msxml3.dll, but that did not have any effect.
I thought that maybe it was OS related, but I get the same error message on both WinXP and WinNT running IE6.
I also tried creating the ActiveXObject using this (from MSDN)...
var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP.3.0");
This too didn't work.
I am at a loss. Any help would be greatly appreciated.
Thanks in advance,
11-04-2004, 12:00 AM
11-04-2004, 02:15 PM
Yes, I am in the same domain. As a matter of fact, we set the JS domain (as in document.domain) equal to the domain we are in. Also, IE has been set to allow access to data sources across domains (Tools>Internet Options>Security>Local Intranet>Custom Level>Miscellaneous).
11-04-2004, 04:18 PM
What happens. and what values are you given, if you try to read out the readystate and status related properties of the object? They might give a clue.
(As for the error, does it have any name, or is it just that number? The number doesn't match the numbering system for JScript or Win32 errors, so looking in the error tables didn't give anything.)
11-04-2004, 05:20 PM
I'm sorry, I meant to post the values for the statusText and readyState properties in my original question.
The statusText property returns "OK" and the readyState property returns "4".
If I call the responseBody property instead of responseText, it does return something (putting it into an alert() shows a bunch of weird characters) and no error message is returned.
Here's a little background on what I am trying to accomplish...
A user opens a custom form that has one input element on it for them to enter a last name. When the user clicks, "Get Names", it fires off a JS function. After some basic validation, the XMLHTTP object is created and passed the URL referenced in the original post. Part of the URL contains the name entered in the input box and is passed in the query string as a parameter. This URL is a corporate owned ASP solution that looks up names out of a PeopleSoft directory, which contains everyone in the organization. The response from this is a generic, corporate form that lists all the names that match the last name entered. What I am doing is "intercepting" this response, using a bunch of String.replace()'s to remove their stuff and replace it with my custom stuff, while still retaining the returned value. This is displayed to the user as if it were part of the application in which they are using.
One of the other error messages I saw (I cannot reproduce it though) was...
MSXML3.dll: (some hex number) System error: -1072896658
I too looked for that error message via Google and MSDN and came up with nothing, until I tried searching without the negative sign in front of the number. I came up with some results, one of which can be viewed at...
I'm not sure if the end solution applies, because I'm not sure what they are referencing when they talk about "white space". By the way, here is the output from the getAllResponseHeaders() method...
Date: Thu, 04 2004 16:12:57 GMT
Thanks for your help...
11-04-2004, 06:15 PM
Hmm, this error is nothing I've seen before. It might be that the problem lies in the character encoding (why the heck are people using a subset of US-ASCII when US-ASCII is ubiquitous and recognised everywhere, in difference from ISO-646?) being unrecognised, or possibly even unhandled, by MSXML. It might be that MSXML hands the data to the JScript engine in the wrong form, such as handing the raw 8-bit string to the JScript engine, which expects a 16-bit UCS-2 encoded string. It might be that the "646" charset is not recognised as ISO-646 and thus wrongly handled. It might be that the browser doesn't support different encodings between the document and the request.
Note that I might be searching for the error in the wrong place and that it's not at all connected with the encoding. I can't tell what's happening, really, not without being able to look the error up.
11-04-2004, 08:03 PM
Again, thanks for your insight on this.
Here is what I have found out. First, the URL I supplied (which is a new one that contains the names of individuals from two heritage organizations combined in one place) does not go to an ASP application, instead it goes to what appears to be a web service written in Java (if I don't pass params in the query string, it returns a null pointer exception!!!). If I use the old URL that does go to the ASP app, then it works fine and I do not get any errors. Here are the response headers using the old URL...
The Content-Type header only specifies "text/html". No reference is made to the charset. What I still find interesting is that the new URL works fine in IE5.5, but does not work in IE6. Is there some kind of IE6 setting when it comes to character sets?
11-04-2004, 09:12 PM
If anything, if would be ie6w supporting the encoding while earlier versions doesn't and instead defaults to win-1252. Since ISO-646 is win-1252 compatible it would work okay, but when the encoding is supported something goes wrong.
That is purely speculation, though. I don't know enough about the inner workings of JScript, COM, MSXML, the networking (HTTP) layer and OS string handling to be able to say anything definite.
The best suggestion for a possible solution I can offer you is to go server side, make sure to convert the request reply to UTF-8, ISO-8859-1 or US-ASCII in a server script, and use that instead.
11-05-2004, 05:34 PM
Thanks for all of your help with this. Your suggestions have pointed me in directions that I probably wouldn't have thought of.
To bad there isn't a "setResponseHeader" method of XMLHTTP that would allow me to change the Content-Type header being sent back from the server (assuming this would even have an effect). I tried using the setRequestHeader method, but after drinking a Coke, I realized it is not the request header I am interested in. I doubt I will have any success in getting the corporate server folks to change the Content-Type being set on their end.
I was able to get output using the responseBody property, but in its current state, it is unusable. Do you think there is a JS solution to convert this output to something usable, or am I just grasping at straws?
11-05-2004, 07:03 PM
To bad there isn't a "setResponseHeader" method of XMLHTTP that would allow me to change the Content-Type header being sent back from the server (assuming this would even have an effect). I tried using the setRequestHeader method, but after drinking a Coke, I realized it is not the request header I am interested in. I doubt I will have any success in getting the corporate server folks to change the Content-Type being set on their end.Have you tried setting the Accept-Charset header? That might make the server transform it.I was able to get output using the responseBody property, but in its current state, it is unusable. Do you think there is a JS solution to convert this output to something usable, or am I just grasping at straws?It might, it depends on how the responseBody relates to the responseText. From the MSDN documentation it seems like responseBody is undecoded and varies depending on encoding. responseText on the other hand seems to assume a unicode encoding, defaulting to UTF-8.
The thing is, UTF-8 is US-ASCII compatible, and ISO-646 is the charset upon which US-ASCII builds. So, I don't see why the default encoding can't read the response and return it in responseText. Possibly the cause is that the response isn't really encoded in ISO-646, or that it contains null characters. Anyway, the responseBody is this raw response as an array of unsigned bytes. This means that you have to figure out exactly what is happening if you want to return the ISO-646 code points. The JScript string is 16 bit, assumes UCS-2. If the response is an 8-bit encoding such as ISO-646 or UTF-8, it might be that each character in the the JScript string contains a pair of original encoding characters. If the response is 16-bit, it might be that the responseBody is an array of 8-bit values that each contain half a 16-bit original encoding character, and the JScript string thus contains a lot of 16-bit values that each contain just 8-bit values that has to be merged to get the original character. I'm not sure it's worth the effort to decode this client side, if you can get a server side script to do the decoding for you. If you can't, you have to start with some bitwise manipulation on the strings to get the original string.
11-08-2004, 02:57 PM
Some searching around the internet via Google over the weekend provided a solution to the problem.
First, however, I tried setting the Accept-Charset header, but it failed to deliver.
The solution was posted by an unamed individual on somebody's team (here's the URL: http://www.forum4designers.com/archive25-2004-7-83279.html). It uses the responseBody output, but converts it from its binary form to a string using a VBScript function called from within the JS function. Here is a code snippet...
//instantiate xmlhttp object here
//open xmlhttp object
//set request header fields
//send xmlhttp object
var origHTML = objHTTP.responseBody;
//here is where you would then manipulate the html
For I = 1 to LenB(Binary)
S = S & Chr(AscB(MidB(Binary,I,1)))
BinaryToString = S
Even though it has to loop over the entire length of the binary input, it is suprisingly fast, and best of all, it works in IE5.5w and IE6w.
Liorean, I just want to thank you again for all of your insight on this problem. Without it, I would never have thought to look into certain "avenues" for a resolution. Thank You!!!
12-15-2004, 03:12 PM
See more about the Microsoft XMLHTTP ActiveX object at...