Thread: XMLHttpRequest, IE6, SSL , and 12030 error - what is the solution?

Back to category: Ajax

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 " Applause

ump 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

mac

hines I might fail faster than on a wicked fast

mac

hine 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

quote author=kjohnston link=topic=442.msg2891#msg2891 date=1187372987

Have either / both of these really worked for anyone? I am guessing by the topic " Applause

ump 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 "dr

AJAX

.js"
<script type="text/

javascript

" src="dr

AJAX

.js" language="

javascript

"></script>

// Create an instance of the

AJAX

module
var obj

AJAX

= new dr

AJAX

();
// obj

AJAX

.url ::: Accepts formats http://locaserver/path, ./Path, ../Path and /Path
obj

AJAX

.url = '/YourPage.

asp

x';
// obj

AJAX

.addData() ::: Add Form data, QueryString or even Head data
// Name & Value, Type = "HEAD", "FORM" or "QUERY" (Also accepts "H", "F" and "Q" Applause

obj

AJAX

.addData(Name, Value, Type);
// obj

AJAX

.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
obj

AJAX

.target = 'JSFuncName';
// obj

AJAX

.send() ::: To initiate the

AJAX

request
obj

AJAX

.send();

function JSFuncName(objCurrent

AJAX

{
// objCurrent

AJAX

::: The

AJAX

Object initiated created above - even if you destroyed it
// objCurrent

AJAX

.status ::: HTTP Status code of request (e.g. 200, 404 etc - Not had 12030 yet)
// objCurrent

AJAX

.response ::: Data returned from server
// objCurrent

AJAX

.elapsed ::: Time taken for request to complete (in milliseconds)
// objCurrent

AJAX

.method ::: Method used for request ("POST" or "GET" Applause

// objCurrent

AJAX

.queryData ::: Data appended to the URL ("?Param1=Value1&..." Applause

// objCurrent

AJAX

.formData ::: Data supplied from form ("?Input1=Value1&..." Applause

// objCurrent

AJAX

.headData ::: Request Header Data submitted
// objCurrent

AJAX

.header ::: Header for response
};

Dragonlaird

quote author=Dragonlaird link=topic=442.msg3763#msg3763 date=1192820901

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

var drObj

AJAX

= false; // Temp holder for dr

AJAX

object when submitting a request

function dr

AJAX

() {
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(drObj

AJAX

&& drObj

AJAX

.xmlHttp) {
// Request in progress - abort it
drObj

AJAX

.xmlHttp.abort();
var dummyVar;
drObj

AJAX

= 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 Address 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 relative to current page (./ or ../) or relative 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('INTE

RNET

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="dr

AJAX

"', 'h');
//this.addData('Connection', 'close', 'h');
};
this.xmlHttp.onreadystatechange = dr

AJAX

Return;
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();
drObj

AJAX

= this;
if(drObj

AJAX

.method == 'POST') {
drObj

AJAX

.xmlHttp.send(this.formData.substr(1));
}
else
{
drObj

AJAX

.xmlHttp.send(null);
};
};

function dr

AJAX

Return(sItem) {
if(!drObj

AJAX

|| !drObj

AJAX

.xmlHttp || !drObj

AJAX

.xmlHttp.readyState) {
return false;
};
if(drObj

AJAX

&& drObj

AJAX

.xmlHttp.readyState != 4) {
return false;
};
var sTarget = false;
drObj

AJAX

.elapsed = (new Date).getTime() - drObj

AJAX

.startTime;
drObj

AJAX

.status = drObj

AJAX

.xmlHttp.status;
if(drObj

AJAX

.xmlHttp && drObj

AJAX

.xmlHttp.text) {
drObj

AJAX

.response = drObj

AJAX

.xmlHTTP.text;
};
if(drObj

AJAX

.response == '' && drObj

AJAX

.xmlHttp && drObj

AJAX

.xmlHttp.responseText) {
drObj

AJAX

.response = drObj

AJAX

.xmlHttp.responseText;
};
drObj

AJAX

.header = drObj

AJAX

.xmlHttp.getAllResponseHeaders();
if(drObj

AJAX

&& drObj

AJAX

.target) {
sTarget = drObj

AJAX

.target+'(drObj

AJAX

);';
};
if(sTarget) {
eval(sTarget);
};
drObj

AJAX

.xmlHttp.abort();
var dummyVar;
drObj

AJAX

= 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

quote author=perkiset link=topic=442.msg3775#msg3775 date=1192832329

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

mac

hine 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

quote author=Dragonlaird link=topic=442.msg3784#msg3784 date=1192864879

Well, I'm still testing it fervently throwing every

mac

hine 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 ap

pear

ed, 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 ap

pear

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

mac

hine 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

quote author=perkiset link=topic=442.msg3799#msg3799 date=1192908021

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

mac

hines using IE 6 & 7 against the test server (50 ms delay between each request on each

mac

hine) and so far each

mac

hine 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

mac

hine I have, using every browser on installed on each

mac

hine, 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

mac

hines 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

quote author=perkiset link=topic=442.msg3819#msg3819 date=1192993818

(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.

quote author=perkiset link=topic=442.msg3819#msg3819 date=1192993818

... 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 ap

pear

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 ap

pear

ed 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?

elbarto

Hi guys...
I joined the forum as is the only place where I found a deep analysis of this problem with IE.

I found out about this error a couple of weeks ago while reviewing a strange behavior on an application which seemed to randomly get sucked on a "loading" message. It turned out to be this 12030 error of IE (together with my lousy

javascript

programming

skils

).

After reading the messages from this thread and this one, I decided to go with the iframes solution, so I coded a little class which emulates the XHR object using iframes and dynamic forms.

This went quite well (despite a couple of problems that I will try to fix later), but while I was testing my whole app again I found another error. There's a part of the site where users can upload an audio file. Of course this was never done with

AJAX

and worked with a hidden iframe from the begining. Now that I'm testing with IE I see from time to time when I try to upload a file that I get the feared ERROR_INTE

RNET

_CONNECTION_ABORTED on my IEWebDeveloperV2 tab.

As you can imagine, this brings me two problems. First, the upload is not working. Second, if I'm having this problem with this iframe nothing assures me that my little class can't have the same problem (athough I haven't seen it yet).

Does anyone know anything about this error ap

pear

ing in a non-

ajax

context? Anything might help me to figure out where I'm wrong.

Thanks in advance

perkiset

Welcome to The Cache elBarto!

Man that sounds horrible - haven't seen that myself. Frigging IE...

since it's your little class doing this, and it's intermittent, I'd suggest writing some form of handshake so that you can see if it failed and then do it again... what a cluster.

Is there no possibility that you could simply do it with a form and a file type field... much like this very board does? I very rarely get problems with uploading that way and when I do it's almost 100% a firewall issue. Is there a specific reason that you must do the file upload outside of the normal structure of the page?

Good luck,
/p

djbiznatch

Okay everyone, I'm struggling with the same problem right now...

My company uses primarily

AJAX

instead of form submits (does that make anyone cringe?) to pass data to our server. We have some client side error/field checking going on, but then we also have potential database issues, so we

AJAX

submit our data, try to do *whatever* with it, and if we get any exceptions, they are passed back into the window which is eagerly waiting for a response. If its a good response, we close the window. If a bad response, we display an error message in a status area. For awhile now, but more frequently as of late it seems, we've had an issue where the users have clicked 'Save' and it seems to hang in certain parts of our application. When we send the data, we lock the button so they get a

javascript

alert to ask them to please wait while its saving. However, minutes go by with no response, so the button remains locked, and they have to close out and come back to enter data again (and may very well have the same problem).

We have a few different means of performing our AJX submits.. some of our code is using prototype.js's

Ajax

.Request object, and others are using a GET or POST method in an

AJAX

api

javascript

object an old co-worker wrote. That was the first place I went to debug this problem, and sure enough, we were only handling a few expected response codes. So we then found out we were getting the 12030 error, and in some cases 12029 (I believe). The users seem to be experiencing the trouble only during POST submits (but the places we ARE using GET should really be POSTs). I tried to modify the

javascript

to resend the request up to three times behind the scenes, hoping that the retry would work (since the error was sporadic).. problem is I can't test these changes easily myself, I have YET to replicate the problem on our system, or over VPN or on one of their terminal servers. So I have to rely on the reports of annoyed customers! Applause

My changes did not work, so I have fallen back on throwing an error, which releases that save buttons lock, and lets them try to resend it themselves. They seem to have luck with this, and can pretty consistently (I was led to believe) save the 2nd try.

I don't know what their IE security settings are, but shouldn't the error be consistent if thats a factor? Also, I think we have customers with the problem running both IE6 and IE7. Many of our customers do NOT seem to have this issue, but I'm not sure if that has anything to do with what parts of our application they are using, or volumn of users,

net

work configuration, yaddy yadda..

Heres the

AJAX

api we use:

function

AJAX

(url, responseHandle) {
this.url = url;
var req = init();
var isPost = false;
var params = '';
this.responseHandle = responseHandle;
req.onreadystatechange = processRequest;

function init() {
if (window.XMLHttpRequest) {
return new XMLHttpRequest();
} else if (window.ActiveXObject) {
isIE = true;
return new ActiveXObject("Microsoft.XMLHTTP");
}
}

function processRequest () {
if (req.readyState == 4) {
if (req.status == 200) {
if(responseHandle)
eval(responseHandle + "(req.responseXML)");
else
postProcess(req.responseXML);
} else if (req.status == 400) {
if(responseHandle)
eval(responseHandle + "(req.responseXML)");
else
postProcessError(req.getResponseHeader("SQL-Error" Applause

);
} else if (req.status == 501) {
if(responseHandle)
eval(responseHandle + "(req.responseXML)");
else
postProcessMessage(req.getResponseHeader("GEN-Message" Applause

);
} else {
req = null;
req = init();
req.onreadystatechange = processRequest;

if(isPost)
this.sendpost(params);
else
this.send();
}
}
}

this.send = function() {
isPost = false;
req.open("GET", url, true);
req.send(null);
}

this.sendpost = function( parameters ) {
isPost = true;
params = parameters;
req.open( "POST", url, true );
req.setRequestHeader( "Content-type","application/x-www-form-urlencoded" );
req.setRequestHeader( "Content-length", parameters.length );
req.setRequestHeader( "Connection", "close" );
req.send( parameters );
}
}

Now we just send the processError() anytime we get a status we didn't expect. I actually had to rewrite some of these changes from memory but I think this is how it was trying to work.. although I'm wondering if saving the POST parameters was written like that.. at one customer they are able to save a second time and its fine (I don't know what is done any differently in clicking Save again and what I tried here), they are the ones that saw the 12030 error. Now I'm hearing that this ISNT working for the other customer, where we saw 12029 (or maybe 12031, i think its the CONNECTION_FAILED one).. So I wonder if theyre timing out somewhere or just flat out not getting a response..

Here's a sample of how we're sending data with the sendpost(params) method:

var

AJAX

= null;
var saving = false;

function save() { // this is a bogus function i just removed alot of extraneous code
saving = true;

var varURL = '<%=pusgActionURL%>/SaveController' // fake controller name
var varParams = 'action=<%= prsgAction %>&clientID=<%= prsgClientId %>'; // there would be alot more data here

ajax

= new

AJAX

(varURL);

ajax

.sendpost(varParams);
}

function postProcess(response) {
if (window.opener && !window.opener.closed)
window.opener.refreshGrid();
window.close();

ajax

= null;
saving = false; //the flag that locked the save button
}

function postProcessError(error) {
document.getElementById('feedback').style.color = red;
document.getElementById('feedback').innerHTML = "ERROR: " + error;

ajax

= null;
saving = false; //the flag that locked the save button
}

Any help would be greatly appreciated.. we need a quick fix on this api if we can now, and then maybe change our method in the long run.. Thanks in advance for any responses

perkiset

Heyya DJ - Welcome to The Cache!

First off, your tale of woe is just so very common now... if you've read all the threads and posts even here on this issue you can see all the different ways that people are trying to solve it - and nothing just yet.

A couple things that seem to be standard for us: we only get it on HTTPS, not HTTP. However, we don't do anywhere near the same volume of unsecured

ajax

that we do secured, so I am no longer convinced that this is a reliable symptom. There are more error numbers, 12029, 12030, 12032 plus several more if you choose to search about here on the board.

If you look in the

javascript

code repository, you can see my personal JS class for request/response which I am now getting pretty close to working reliably - very few errors any more. However, I believe that this is simply good symptom handling, rather than fixing the root cause.

Interestingly, just the other day I posted in another thread on this issue about the possibility that we've all been looking in the wrong place. We've been focused on the request being bad - a new notion is that the *previous* request did not close, and the XMLHTTPRequest in IE only doesn't know how to handle it. The thinking was to add Connection: Close to the outbound packet, which explicitly closes out the request. Although I have no data yet, this is the first time I've seen something more outside the box and it actually makes a bit of sense to me.

Looking over your code briefly, you have a very straight-up JS requestor and there's nothing that sticks out to me. If you look at the

Ajax

Requestor class in the

Javascript

Code Repository, although you will find it much larger, I think you will see that the essential logic is all the same.

PLEASE let us know if you try any of the techniques here and get some success - everyone watching these threads is pretty equally frustrated.

Again, welcome to the cache.
/p

Dragonlaird

quote author=perkiset link=topic=442.msg4110#msg4110 date=1194458962

We've been focused on the request being bad - a new notion is that the *previous* request did not close, and the XMLHTTPRequest in IE only doesn't know how to handle it.

That fits fairly square in the hole for me Perk, although I maintain that the POST request (still can't reproduce the problem with simple GET requests) was badly formed (due to incorrect headers, malformed addresses, invalid POST data etc) which is what causes the request to fail and MS didn't write the code to handle such a situation, hence it simply bombs and forgets to close the connection cleanly.

Eventually the ActiveX object is unloaded by IE during it's occasional clean up (usually about a minute or so later) and the problem disap

pear

s for a while until it experiences another badly formed request.

Belts and braces people, if you don't dot your I's and cross your T's, MS won't let you pass...

How about we examine the RFCs for accurate info on everything we must set to submit a POST(via HTTP and SSL) request and ensure we follow it to the letter?

djbiznatch

Out of curiosity, is anyone using the

Ajax

.Request from prototype.js and having this problem? I was going to try ousting our current

ajax

javascript

in favor of that in a few of these problematic areas and see if that cleared up the problem at all.. I'm wondering if it handles things better or if its just a coincidence that we aren't see this problem in the areas we are using prototype...

Dragonlaird

I'd be lying if I said I was, I published some code earlier in this thread that I've been testing to death with about a dozen or so

mac

hines now running various OSes and Browsers, including several versions of IE... You're welcome to give it a try in your environment and see if it cures your problem... Would be nice to get some feedback from a real-world environment...

http://www.perkiset.org/forum/

ajax

/xmlhttprequest_ie6_ssl_and_12030_error_what_is_the_solution-t442.0.html;msg3764#msg3764

pruzze

quote author=djbiznatch link=topic=442.msg4131#msg4131 date=1194561915

Out of curiosity, is anyone using the

Ajax

.Request from prototype.js and having this problem? I was going to try ousting our current

ajax

javascript

We're using prototype, and we still get this problem with IE6 over SSL Applause

/Fredrik Pr�zelius
www dot dse dot se

Hannnibal

From the other 12030 thread.

quote author=pruzze link=topic=249.msg4376#msg4376 date=1196869069

Please look here for a good explination of the problem: <edit - removed external link>

/Fredrik Pr�zelius
www dot dse dot se

We have been experiencing the 12030 problem as well. Perkiset, your observation about the previous request socket remaining open is consistent with what we saw during out examination of the problem. I believe adding Connection : close to the header ensures that that the socket will close. It does disable the Keep alive functionality which will add a little overhead but as the article that Fredrik posted stated, the server has already closed that socket anyway. We altered our Prototype file to include Connection : close on the header for all POST actions and that seemed to mitigate the 12030 problem.....

Until this afternoon when it a tester saw it again (and only once the entire day) in our non-SSL integration environment. The error has not been seen again but we added some retry code to the Prototype framework to reissue the request on a 12030 error and log the error just in case. If it happens again, we'll know about it. In the meanwhile I've been playing with Dragonlaird's header code. I am unable to set the Content-Length header. Everytime I set it and make the

ajax

call, the captured header seems to have been overwritten with the length of the parameters string I passed in. I have a few ideas regarding the content-length being out of sync with the real length of the body but I'm unable to test it because I can not seem to manually set the Content-Length header. Dragonliard, could you post a little code demonstrating your method for manually setting the Content-Length? I would greatly appreciate it.

Hannnibal

Sorry Dragonliard, I see you posted your code in another thread.

pruzze

quote author=Hannnibal link=topic=442.msg4380#msg4380 date=1196978607

We altered our Prototype file to include Connection : close on the header for all POST actions and that seemed to mitigate the 12030 problem.....

We're using prototype, and made the a fix in our own framework that is build on top of prototype, but it would be nicer to make the fix in prototype it self. Could you post the patch here?

/Fredrik

djbiznatch

just so you all know, i did make the switch to using prototype and it seems to have resolved our problems. our customers are using a mix between IE6 and 7, but I don't think anyone is using SSL. If they were, I guess we might still see the problem.. but for now I'm happy!

Hannnibal

The prototype files are rather large but the change was quite simple. I'm not sure which version you are using (I think we are using 1.4 for some crazy reason). In the

Ajax

.Request.setRequestHeaders function add the line requestHeaders.push('Connection', 'close'); to the if statement that sets some headers if you are performing a post action.

kjohnston

Hey all - I just wanted to chime and say yes - adding "Connection: close" to every request does work. I actually posted this solution in this same thread a while back - and I hadn't revisited this forum until I got the "happy holidays" email. :-)

Since adding the Connection: close to every SSL

Ajax

request, I have not seen the dreaded 12030 error one single time, on either IE6 or IE7 - and this is on a product that has now been through many QA cycles.

The only drawback to this solution is that there might be a slight performance hit - as this prevents IE from reusing the same SSL socket on a subsequent request.

perkiset

Man that is JUST the kind of corroboration I've been looking for... right on KJ. Think it's time to revisit that whole side of things...

Thread Categories

		Best of The Cache Home
		Search The Cache