next »

[kjohnston]

This is the only board where I have found any suggestions of a solution.

I have tried using relative URLs - I still get the 12030 error.
I have tried setting a timeout between the openRequest and the send - I still get the 12030 error.

Have either / both of these really worked for anyone?  I am guessing by the topic "Dump XMLHttpRequest" that maybe there still is no solution that actually works?

[perkiset]

Hey KJ, welcome to The Cache!

IME, I did not reliably make any solution stick 100% of the time. The timeout between open and send worked for me about 98% of the time, the other possible solves did little to make any effect. I was never able to 100% finger the culprit, although as you've no doubt read in the threads that there's a lot of speculation that is probably pretty close to it.

I have abandoned XMLHTTPRequest completely on new stuff. My older stuff still uses it, but in the case of client apps I've just pushed them all into FF or Safari and that solved it instantly. I have had fantastic success with the code that I posted there - it has the benefit of effortlessly moving between ports, URLs, you name it - my web services are richer and easier than ever before. Additionally, none of the browsers complain about "Part of this website is insecure" like if you have http graphics on an https site... it's pretty under the radar.

So I guess the answer that you don't want to hear, is yes - I think that some (particularly me) have become dissillusioned enough to move on.

Post back tho, if yawanna talk more about it...
/p

[kjohnston]

Thanks for the welcome!  And thanks for all your postings on this problem.

I went back to your original post - where you suggested testing for the 12030 error and retrying the request.  THAT seems to work 100% of the time.

Unfortunately we cannot get rid of XMLHttpRequest just yet due to time constraints but I will definitely check out your suggested replacement.

[perkiset]

I'm glad you're getting good results... looking back over my notes it does seem that we nailed that one pretty good and I was somewhat mistaken in my last post.

The reason that I moved on was because of the lack of flexibility in XHR rather than that bug - I had to create a new mashup mechanism and XHR can not make the cut. So in wrapup, I recommend you look at that technique as another tool in your box, but if you've gotten XHR working perfectly then it's just a great "also."

Good luck!
/p

[kjohnston]

So I spoke too soon.  It looks like the retry works most of the time - but I still had issues.

What I am now doing is adding to the request headers the "Connection" attribute with "close" as the value.  This forces the server to close the connection after each request, which seems to make IE also clean up the socket cleanly.

It looks like the problem with IE is that it does not cleanly close the sockets.

Will post back here if *this* solution doesn't work. With this fix I don't think I even need the retry logic.

[perkiset]

My challenge was not the close - it was that IE never threw the request at all. I never saw *anything* at my server - the request was instantly bungled up. So by seperating the open from the send I got pretty close, then with the timeout and resend I got closer.

Now thinking about it, I should have looked to see what the dispatch time and the failure time was... if it was *that* close together every time I could have trapped for that event... except that on slower machines I might fail faster than on a wicked fast machine and a fat pipe...

Good luck man - this one just *pissed me off* for too long - that's why I amn't using it in future apps.

/p

[Dragonlaird]

Have either / both of these really worked for anyone?  I am guessing by the topic "Dump XMLHttpRequest" that maybe there still is no solution that actually works?

Hi Guys...

I've discovered another cause of the 12030 problem - and a solution of course...

The post after this is a JS file to create an AJAX sender I created - Sorry but very few comments in the code but so far, I've not managed to break it in IE...

Usage:
// Include the script in your document HEAD section - I'd suggest saving is as a file "drAJAX.js"
<script type="text/javascript" src="drAJAX.js" language="javascript"></script>

// Create an instance of the AJAX module
var objAJAX = new drAJAX();
// objAJAX.url ::: Accepts formats http://locaserver/path, ./Path, ../Path and /Path
objAJAX.url = '/YourPage.aspx';
// objAJAX.addData() ::: Add Form data, QueryString or even Head data
// Name & Value, Type = "HEAD", "FORM" or "QUERY" (Also accepts "H", "F" and "Q")
objAJAX.addData(Name, Value, Type);
// objAJAX.target ::: Name of JS function to call upon completion, passes this AJAX Object as an argument
// Sample function created below to highlight remaining properties etc
objAJAX.target = 'JSFuncName';
// objAJAX.send() ::: To initiate the AJAX request
objAJAX.send();

function JSFuncName(objCurrentAJAX) {
    // objCurrentAJAX ::: The AJAX Object initiated created above - even if you destroyed it
    // objCurrentAJAX.status ::: HTTP Status code of request (e.g. 200, 404 etc - Not had 12030 yet)
    // objCurrentAJAX.response ::: Data returned from server
    // objCurrentAJAX.elapsed ::: Time taken for request to complete (in milliseconds)
    // objCurrentAJAX.method ::: Method used for request ("POST" or "GET")
    // objCurrentAJAX.queryData ::: Data appended to the URL ("?Param1=Value1&...")
    // objCurrentAJAX.formData ::: Data supplied from form ("?Input1=Value1&...")
    // objCurrentAJAX.headData ::: Request Header Data submitted
    // objCurrentAJAX.header ::: Header for response
};

[Dragonlaird]

Next post is a JS file to create an AJAX sender I created - Sorry but very few comments in the code but so far, I've not managed to break it in IE...

// JScript File

Code:

var drObjAJAX = false; // Temp holder for drAJAX object when submitting a request

function drAJAX() {
    this.url = '';
    this.port = window.location.port;
    this.errorCount = 0;
    this.protocol = window.location.protocol;
    this.send = drSendRequest;
    this.xmlHttp = false;
    if(window.XMLHttpRequest) {
            this.xmlHttp = new XMLHttpRequest();
    }
    else if(window.ActiveXObject)
    {
        this.xmlHttp = new ActiveXObject('Microsoft.XMLHTTP');
    };
    this.queryData = '';
    this.formData = '';
    this.headData = '';
    this.addData = function (sName, sValue) {
        var sType;
        if(arguments.length > 2) {
            sType = arguments[2];
        }
        else
        {
            sType = 'Q';
        };
        if(typeof sType != 'string') {
            try {
                sType = sType.toString();
            }
            catch(e)
            {
                sType = 'Q';
            };
        };
        if(typeof sName != 'string') {
            try {
                sName = sName.toString();
            }
            catch(e)
            {
                sName = '';
            };
        };
        if(sName == '') {
            return false;
        };
        if(typeof sValue != 'string') {
            try {
                sValue = sValue.toString();
            }
            catch(e)
            {
                sValue = '';
            };
        };
        sType = sType.toUpperCase();
        switch (sType) {
            case 'F':
            case 'FORM':
                if(this.formData.indexOf('?') == -1) {
                    this.formData += '?';
                }
                else
                {
                    this.formData += '&';
                };
                this.formData += escape(sName);
                this.formData += '=';
                this.formData += escape(sValue);
                this.method = 'post';
                break;
            case 'H':
            case 'HEAD':
                this.headData += sName + '=' + sValue + String.fromCharCode(13);
                break;
            default:
                if(this.queryData.indexOf('?') == -1) {
                    this.queryData += '?';
                }
                else
                {
                    this.queryData += '&';
                };
                this.queryData += escape(sName);
                this.queryData += '=';
                this.queryData += escape(sValue);
                this.username = '';
                this.password = '';
        };
        return true;
    };
    this.elapsed = 0;
    this.response = '';
    this.method = 'get';
    this.target = null;
    this.status = 0;
    this.startTime = 0;
    this.header = '';
};

function drSendRequest() {
    var sTemp = window.location.protocol.toUpperCase()+'//';
    if(drObjAJAX && drObjAJAX.xmlHttp) {
        // Request in progress - abort it
        drObjAJAX.xmlHttp.abort();
        var dummyVar;
        drObjAJAX = dummyVar;
    };
    if(this.url.toUpperCase().indexOf(sTemp) == 0) {
        // Absolute address - check it is local
        sTemp += window.location.host.toUpperCase();
        if(this.url.toUpperCase().indexOf(sTemp) != 0) {
            // Not local - abort
            alert('Invalid Address - Cannot open any page external to this site\nAddress must begin with \''+sTemp.toLowerCase()+'/\'');
            return false;
        };
    }
    else if(this.url.indexOf('/') != 0 && this.url.indexOf('../') != 0 && this.url.indexOf('./') != 0)
    {
        // Does not start with './', '../' or '/'
            alert('Invalid Address - Page must be\nrelative to current page (./ or ../) or\nrelative to the site root (/)');
            return false;
    };
    this.method = this.method.toUpperCase();
    if(this.formData.length > 0) {
        this.method = 'POST';
    }
    else
    {
        this.method = 'GET';
    };
    //if(navigator.appName.toUpperCase().indexOf('INTERNET EXPLORER') != -1 && this.formData.length > 0) {
    //    debugger;
    //};
    if(this.username && this.username.length > 0) {
        this.xmlHttp.open(this.method, this.url+this.queryData, true, this.username, this.password);
    }
    else
    {
        this.xmlHttp.open(this.method, this.url+this.queryData, true);
    };
//    this.addData('Content-Type', 'application/x-ww-form-urlencoded; charset=utf-8', 'h');
    this.addData('Content-Type', 'application/x-www-form-urlencoded', 'h');
    if(this.method == 'POST') {
        this.addData('Content-Length', this.formData.length - 1, 'h');
        this.addData('Content-Disposition', 'form-data; name="drAJAX"', 'h');
        //this.addData('Connection', 'close', 'h');
    };
    this.xmlHttp.onreadystatechange = drAJAXReturn;
    if(this.headData.length > 0) {
        var sHead = this.headData;
        var sName = '';
        var sValue ='';
        while(sHead.indexOf('=') > 0) {
            sName = sHead.substr(0, sHead.indexOf('='));
            if(sHead.indexOf(String.fromCharCode(13)) > 0) {
                sValue = sHead.substr(sName.length+1, sHead.indexOf(String.fromCharCode(13)) - (sName.length + 1));
                sHead = sHead.substr(sHead.indexOf(String.fromCharCode(13)) + 1);
            }
            else
            {
                // Last Head entry, no Carraige Return found (?)
                sValue = sHead.substr(sName.length+1, sHead.length - (sName.length+1));
                sHead = '';
            };
            if(sName.length > 0) {
                this.xmlHttp.setRequestHeader(sName, sValue);
            };
        };
    };
    this.elapsed = 0;
    this.startTime = (new Date).getTime();
    drObjAJAX = this;
    if(drObjAJAX.method == 'POST') {
        drObjAJAX.xmlHttp.send(this.formData.substr(1));
    }
    else
    {
        drObjAJAX.xmlHttp.send(null);
    };
};

function drAJAXReturn(sItem) {
    if(!drObjAJAX || !drObjAJAX.xmlHttp || !drObjAJAX.xmlHttp.readyState) {
        return false;
    };
    if(drObjAJAX && drObjAJAX.xmlHttp.readyState != 4) {
        return false;
    };
    var sTarget = false;
    drObjAJAX.elapsed = (new Date).getTime() - drObjAJAX.startTime;
    drObjAJAX.status = drObjAJAX.xmlHttp.status;
    if(drObjAJAX.xmlHttp && drObjAJAX.xmlHttp.text) {
        drObjAJAX.response = drObjAJAX.xmlHTTP.text;
    };
    if(drObjAJAX.response == '' && drObjAJAX.xmlHttp && drObjAJAX.xmlHttp.responseText) {
        drObjAJAX.response = drObjAJAX.xmlHttp.responseText;
    };
    drObjAJAX.header = drObjAJAX.xmlHttp.getAllResponseHeaders();
    if(drObjAJAX && drObjAJAX.target) {
        sTarget = drObjAJAX.target+'(drObjAJAX);';
    };
    if(sTarget) {
        eval(sTarget);
    };
    drObjAJAX.xmlHttp.abort();
    var dummyVar;
    drObjAJAX = dummyVar;
};

[perkiset]

DLaird -

Given what we all know about the 12030++ problems, what do you think it is about your code that doesn't seem to break IE? I don't see anything in there that seems substantially different (cursory look tho) - And how hard have you tested it? I really didn't see the problem until I stuck it on a bunch of users' IE and let'r rip... then it was spontaneous and frappin' impossible to reproduce reliably... man I hope you have something here...

<edit>
The example you passed me is not SSL - it's normal HTTP - my problem is exclusively when I use AJAX mechanisms over HTTPS...
</edit>

[Dragonlaird]

Given what we all know about the 12030++ problems, what do you think it is about your code that doesn't seem to break IE?

Well, I'm still testing it fervently throwing every machine I have at it with different flavours of IE to see if my theory is right. In the meantime, let me explain what I've found regarding the 12030(et al) errors...

First time I encountered this problem, it wasn't limited to SSL (I am testing a theory with SSL later today).

Like most developers, I hunted around for a cause/solution and found for once the web was sadly lacking, this annoyed me (you have no idea how much) as I've NEVER let a problem beat me before, I've always found either a solution or an acceptable work-around and I was damned i if something as silly as an intermittent error was gonna stop me.

At first, I believed the problem was due to how the page was being addressed, e.g. absolute, relative etc and for a while fixing this cured my problem and so I moved on.

Earlier this week however, a slight change to my application caused this error to rear it's ugly head again and so I decided to investigate the problem in isolation with a view to finding a cure and publishing the code (if any) to help anyone else out there suffering this nuisance.

Back to the drawing board I went, and started a new AJAX Requestor from scratch, testing with various browsers along every step of the way, after reaching a certain point, my old friend 12030 popped up to say hello. This was great, it was just what I'd been waiting for.

I examined the request and response, along with the contents of the data stream being sent to the server (or lack thereof) and discovered several things.

1. The error can be caused by poorly formatted addresses, specifically those addresses that are relative to the current path but don't begin with './'
2. The problem can be reproduced almost 100% if using the POST method (I don't think I saw it once using GET)
3. The frequency of the problem altered if the request header contained different name/value pairs
4. The problem wasn't restricted to a specific version of the MS ActiveX component (in fact IE7 uses a built-in requestor like FF etc)

So my experimenting began, I created a simple test page to fetch the results of the data submitted to the server so they could be compared on the odd occasion the request didn't actually generate an error. This was a very useful exercise because that's how I discovered some subtle differences.

The data being sent to the server (when it actually returned a result) didn't match the data I'd submitted, especially the FORM data (which never arrived) and the HEAD data (which seemed to differ).

A lot of tinkering, investigating and general playing around, after reading various iterations of RFC2616 and several discussions about it, I discovered there were certain REQUIRED header tags to be used for POSTing data - Furthermore, a few optional ones I could also experiment with.

I also found the format of POSTed data was critical, not just the fact it had to conform to the usual URL encoding (assuming this is the method entered in the HEAD) but a simple character out of place when submitting the data could also cause a problem (e.g. the rsulting data looked exactly like a normal QueryString but the big different is, it DOESN'T start with a '?').

Finally, after all the tinkering, playing, reading, experimenting and swearing (12030 was rapidly losing the 'friend' status I gave it earlier) I found a combination that didn't generate any errors.

Knowing I'd been here before, I decided to try and break it by changing the method of addressing used to retrieve the test page. I tried absolute (http://...), nope - it still worked... So I tried relative to the root (/Path/...) that worked too... Grrrr.... So out of desperation I tried a convoluted combination of every type I could think of (something like http://Host/Path1/.././Path2/./../Path3/File.ext) and even that worked fine...

Ever wanted a problem to occur and it just wouldn't? And so I posted the code here for all to play with, I've tested it with IE, FF, NS, Safari and Opera and so far, no problem. I've tested it with FORM data, QUERY data, both and neither (the requestor changed the method automatically) and so far, it hasn't broken. Today I plan to test it using SSL but I'm fairly confident...

So what is this magical combination?

1. Only use POST if you're actually submitting FORM data (no data but still using POST upsets it, use GET if there's not data or only QUERY data to send).

2. When submitting FORM data, ensure there is no preceding '?' (e.g. ?P1=V1&P2=V2 is wrong, but P1=V1&P2=V2 is fine)

3. If POSTing data, set the HEADer of your request using the following:
    Content-Type: application/x-www-form-urlencoded    (This should also be set when using the GET method)
    Content-Length: (Length of FORM data)
    Content-Disposition: form-data; name="YourAppName"

If you set the request HEADer to exactly match the contents of the request being submitted, the ActiveX object submitting the request doesn't seem to get upset and the server happily sees and reads everything you've sent...

So please feel free to have a play with the code I've submitted above and post back results of any experiments, I'd particularly like to hear from anyone who still suffers any 12030 errors etc and the configuration they used to create them, I'll be damned if this little friend of mine is going to beat me... You started the challenge on another thread Perk, I'm simply picking up the gauntlet...

[Dragonlaird]

Well, I'm still testing it fervently throwing every machine I have at it with different flavours of IE to see if my theory is right.

I've added an SSL certificate to my test server and expected the site to die horribly... I had the obligatory 'Invalid Certificate' message when I went to the site, in a lovely red page so the sense of foreboding increased as I accepted the self-generated certificate and proceeded to the test page...

The page appeared, looking the same as it does using HTTP but I suspected I was being lulled into a false sense of security by my friend the 12030 error and he was lurking in the background waiting to strike...

With one eye closed and the other squinting at the screen, I pressed my test button on the page and waiting for the horrible red writing to appear to tell me the error code...

Have you ever noticed that, even though a request to a website only takes seconds (or microseconds in this case, the server is on my LAN) it seems like an eternity when you're waiting for it to respond and expecting the worst?

And sad to say, I was disappointed, the error wasn't there... In fact, apart from taking a few microsecnds longer than usual, there wasn't a problem at all...

Then I realised, I was using IE7, this problem manifests itself mostly in IE6 - so off to my missus machine I went (she never applies updates, patches etc - and to think I kept moaning at her about it... Thanks you darling) and fired up IE6.

Guess what... It worked on there too!

Uh-oh, what about FF etc? Nope, they still work... So what's the catch?

Could this be the cure? Please guys, play with the code above it and let me know what you find...

[perkiset]

DL I'm gonna look at your code and try to rebuild the test environment that I had to work through my issue.

HOW I WISH it was that easily reproducible. I can't tell you how many times I thought I had it nailed, it'd work for a week or two and then BLAM I'd get some problems with a client. On my systems I have a bitch of a time reproducing it. The problem is that it is (seemingly) completely random and I cannot pin down what causes it. Sometimes I'd put up a solution, hit my test box a thousand times with nothing - then come back an hour later and within 10 hits I'd get one.

Problem does not present (for me at least) anywhere except IE6. PC speed does not seem to affect it one way or the other. Since it is (rather) limited and IE7 does not do it, I've told my clients to go FF until IE7 is ubiquitous and then I'll be fine. For my retail apps I've been using the XRPC for the secure stuff (which is one or two calls) and my ajax components for everything else (lower overhead) and it's been pretty great.

[Dragonlaird]

Problem does not present (for me at least) anywhere except IE6. PC speed does not seem to affect it one way or the other. Since it is (rather) limited and IE7 does not do it

Fingers crossed. Whilst writing the module above I managed to reproduce the error in IE7 plus it wasn't just limited to SSL so with any luck, my system(s) suffered the problem even more than most which is a good thing (from a testing point of view).

I plan to set up an automated test later today to just keep firing requests - I'll see what that does...

Update: I've been running 3 different machines using IE 6 & 7 against the test server (50 ms delay between each request on each machine) and so far each machine has run over 5000 tests each without error... How's your tests going Perk?

Update 2: OK, I've been running tests on every client machine I have, using every browser on installed on each machine, for over an hour... I've even run tests on the server itself (just to add extra load) and multiple instances of browsers...

For the technophiles out there, that's 5 machines running 4 x IE7, 2 x IE6, 2 x FF, 2 x Opera, 2 x Safari, 1 x NS...

I've fired in excess of 100,000 requests (I daren't look at the log file for this site today), with different configurations and changing values (to prove it isn't cached results the browser is working with) and apart from the fact my web server just smiled at me then yawned at being bored... Not a single error!

I'm gonna go out on a limb here and reverse the challenge Perk, prove this ISN'T a fix to the 12030 problem...!

[perkiset]

"Prove that there ISN'T global warming..."

DL the problem neve comes up anywhere for me ever except IE6 (some folks claim that IE7 exhibits it now and again) and it is utterly random. Have not yet gotten a free couple hours to get this setup to test...

... but here's my question: other than simply rewriting an Ajax requestor from the ground, what, specifically, do you think is "the fix?" Or more preciesly, what, specifically do you think is the problem with others? I've gone *months* without seeing it, and then it will pop up her and there for a while. And just so you know as well... the only tests where I've managed to generate it are when I sit and literally force the request by hand, randomly and seemingly "naturally" - so it has been utterly impossible for me to reliably reproduce. But goddamit if my clients don't see it often enough to go, "What the heck was that?"

[Dragonlaird]

(some folks claim that IE7 exhibits it now and again) and it is utterly random.

Firstly, yes IE7 does exhibit the same problem, IE7 now emulates the window.xmlHttpRequest method used in Mozilla but this is just the ActiveX control embedded within the browser.

... but here's my question: other than simply rewriting an Ajax requestor from the ground, what, specifically, do you think is "the fix?" Or more preciesly, what, specifically do you think is the problem with others?

The problem isn't the browser, it's the ActiveX requestor itself being extremely unforgiving if the request is not issued 'perfectly'.

1. The error can be caused by poorly formatted addresses, specifically those addresses that are relative to the current path but don't begin with './'
2. The problem can be reproduced almost 100% if using the POST method (I don't think I saw it once using GET)
3. The frequency of the problem altered if the request header contained different name/value pairs
4. The format of POSTed data must also be exact, it is basically the same as QueryString data but within the preceding '?'

The main difference (after reading several RFC relating to web requests), the header of the request *must* contain certain values and they *must* match the data being sent, if there is even a tiny sniff that these aren't right, it will throw it's rattle out of the pram...

It's a case of Microsoft adhering too closely to the spec (for once) and their application not being able to handle malformed requests intelligently (no surprise there).

The following headers are *required* for POST requests, I wouldn't be surprised if the order they appear is also important I haven't checked that, this combo seems to work fine for me...

    Content-Type: application/x-www-form-urlencoded    (This should also be set when using the GET method)
    Content-Length: (Length of FORM data - without a preceding '?')
    Content-Disposition: form-data; name="YourAppName"

Most requestors add the first one and yes, it will work fine for GET requests, it also usually works for the FIRST POST request but subsequent POST requests will fail as the ActiveX object doesn't close down cleanly and has to wait for the browser to realise the connection has terminated and unload the object from memory.

A few requestors also add the second one but as I've said before, the format of the POST data must be exact and the length declared must be for the data without any preceding '?'.

I haven't seen any code that uses the last header (BICBW) and it's mostly there for belt/braces...

Without doing all the above, I could reproduce the 12030 error almost 100% of the time in either IE6 or IE7 (I was actually glad when it appeared during the rebuild) and as a result, I was able to experiment a great deal to find the combo above...

Note: I've had no timing issues with submitting requests, none of the 'setTimeout..' was needed (although FF does sometimes get a little testy when reading the status of the request when all data is received) - Also, the format of the address isn't as critical as I thought it was originally, the requestor accepts relative, absolute and relative to the root addresses without any difference.

Of course there's still the problem of not being able to access pages on another site and you can't switch between HTTP and HTTPS unless the browser itself reloads the site in SSL first. This is by design, after all, who would believe a website that uses HTTP: in it's address and claims to submit a credit card details via Ajax over SSL?