next »

[perkiset]

OK here's a challenge:

Throwing a request from an XML ActiveX in Internet Explorer 6 when the protocol is SSL is a mess..

It seems that there is a spontaneous error that occurs - randomly and without warning. The error occurs either when you open or post the request - the status is "4" but your will get one of 5 different error codes - 12029, 12030, 12031, 12152 and 12159. These are none-standard errors codes and if you look at the Microsoft site about them, they claim that the server connection died - the implication being that the server cutoff in some way.

The truth of the matter seems to be that the headers did not go correctly or something and no real connection was made - the packet never leaves the box. As far as I know today, it is safe to simply reissue the request because it never made it to the server (this is particularly important in transactional systems using AJAX).

I am seeing one other error but have not locked it down yet.

My response code is simply this (JavaScript)

Code:

switch(this.requestor.status)
{
case 12029:
case 12030:
case 12031:
case 12152:
case 12159:
// OK: It's the IE SSL bug. Create a tiemout to call <me> again...
var loader = this;
setTimeout( function() { loader.execute.call(loader); }, 10);
break;

default:
this.onError(this);
}

... of course this is in the middle of my own ajaxRequestor object so it doesn't make a lot of sense in other contexts EXCEPT to note that a simple case statement and reissue is adequate.

/p

[nutballs]

ya know i have been thinking about this, per our offline conversations about it.

I can't remember if you said it happens for everyone (if you know it does), or if you are only seeing it yourself. Is it possible there is an issue on your setup? firewall, router, or something?

[perkiset]

Actually I've now found a great deal of discussion about it on the net, but no real answers except that it happens in IE6. Well, I should say I've found a great deal of QUESTIONS about it lol - I've not found real answers. The only two places that had any info were one that gave me all of the codes it generated and another that mentioned that the packed did not leave the server - which really helped a lot.

It happens at sites other than here, so it is not <me> specific. It happens on all three of my systems (dev/stage/production) so it is neither OS or distance-to-server specific. The only constant seems to be SSL and version 6.

[nutballs]

ah thats right, we covered that. i just couldnt remember.

I have no other advice other than error trapping which is what your now doing. I don't think there is going to be a "magic bullet" code chunk that will solve it. Especially since its intermittent.

[perkiset]

The magic bullet is either FF or IE 7 lol... frappin' Microsoft...

But as an aside, I've finally learned how to both deal correctly with onerror and try/catch in JS because of this

[coolhand27]

Hey Guys,
I came across your forum when looking for info on this same problem.

I work on a rather large ajax application that is making constant async requests to retrieve and save data. We use a similar "retry" method when encountering the wierd "ie ssl" errors, but have found that for some users their connection never really recovers. We allow the request to retry up to 5 times at which point (in order that that the user not lose data more data) we request them to reload the application.

I've found that only certain users suffer from the problem and that when they do, it seems that others who are on the same network suffer from it as well.

I'd be interested in any further discoveries you make regarding this problem and will keep you posted on my findings as well.

cheers.
LWC

[nutballs]

cool, glad you found the forum. Perk actually is like some kind of freakin AJAX savant, so if a few more good ajax folks get in here, im sure a solution will be figured out.

Im not an ajax guy, but, i do know the tech, and the browsers. this thread came from an offline discussion about why the AJAX requests get lost or hang when from certain browsers, across SSL. Seems to only be SSL if I understood it correctly.

for back reference here's the gist of what we think is going on.
This seems to only happen in IE6. Im guessing its actually only certain versions of IE6, at different patch levels, probably towards the first version or so of it. This would make sense, since AJAX started to grow in popularity so fast, and so many bugs/holes/problems were found initially, that IE6 had some issues somewhere in the middle of patching. Obviously its gotta be a security context issue (at least thats all i can think it is). But my thought is that if you look at the browser patch timeline, i would be willing to bet that all the effected browsers fall within a slice of that patch timeline. for example IE6.04 or whatever. before that timeline the security was wide open, ajax could rape your machine, and hackers rejoiced. then they started patching frantically, which is the bad browsers, until they got it right, which is now the good browsers, with security.

of course that by no stretch solves the problem, but it might give a basis point to work from. possibly, if you could test the browser UserAgent and if its a "bad browser" switch out of SSL. warn them, etc. especially if you finding users are never recovering from the error. i've gotta assume though that this is a fairly small slice of both of your guys traffic?

[perkiset]

cool, glad you found the forum. Perk actually is like some kind of freakin AJAX savant, so if a few more good ajax folks get in here, im sure a solution will be figured out.

Oh fuck - how much Scotch & microbrew is THAT going to cost me?!?! (thanks though NBs)

for back reference here's the gist of what we think is going on.
This seems to only happen in IE6. Im guessing its actually only certain versions of IE6, at different patch levels, probably towards the first version or so of it. This would make sense, since AJAX started to grow in popularity so fast, and so many bugs/holes/problems were found initially, that IE6 had some issues somewhere in the middle of patching. Obviously its gotta be a security context issue (at least thats all i can think it is). But my thought is that if you look at the browser patch timeline, i would be willing to bet that all the effected browsers fall within a slice of that patch timeline. for example IE6.04 or whatever. before that timeline the security was wide open, ajax could rape your machine, and hackers rejoiced. then they started patching frantically, which is the bad browsers, until they got it right, which is now the good browsers, with security.

of course that by no stretch solves the problem, but it might give a basis point to work from. possibly, if you could test the browser UserAgent and if its a "bad browser" switch out of SSL. warn them, etc. especially if you finding users are never recovering from the error. i've gotta assume though that this is a fairly small slice of both of your guys traffic?

Pretty good encapsulation. The net of my research on it has been, pretty much like you say, you're SOL on certain versions of IE. Period. Everything new or even reasonably new seems to be OK.

NBs - unfortunately, I find that the majority of my surfers are coming in on IE 6 right now... it's looking like it's going to be a while before 7 takes hold or there's enough FF/Safari/Whatever else takes hold.

I work on a rather large ajax application that is making constant async requests to retrieve and save data. We use a similar "retry" method
when encountering the wierd "ie ssl" errors, but have found that for some users their connection never really recovers. We allow the
request to retry up to 5 times at which point (in order that that the user not lose data more data) we request them to reload the application.

I'm currently doing a clear and retry on the 12030++ errors, plus my class has a built in timeout feature and I let that run 3 times, and if all
of THAT fails I have everything cookied and a reload the page <whew>. But it's a MASSIVE pain in the butt and there will be some users that I
pssi off in the process I'm sure.

I have a great many applications that are completely ajax based now. All of my control centers for business applications, ops, marketing etc
are user-touched ajax based applications running on lotso different browsers. Fortunately, I have control over my business users - "Frigging
Switch To Firefox You Moolie" is not an available option to me on my surfer-client retail and travel businesses.

I've found that only certain users suffer from the problem and that when they do, it seems that others who are on the same network
suffer from it as well.

This is the most interesting symptom I've heard, provided it is a homogeneous browser environment. I tried to prove that it was a dirty/busy network that was the issue, or a busy machine, or timing to the router, or length of time that IE had been running, or version of XP and and and... I got nono substantial symptoms or evidence at all. It was unpredictable and not even "clumpy" enough for me to see if there was some other fact generating it.

I'm just about done with a retail implementation that traps the problem as best as I can get it. I'll post something here re. my results. Yes NB's, "that's" where it is...

/p

[nutballs]

interesting about the "other users on the same network segment" having problems at the same time. That confirms its a comm-speed issue in my mind.

though, is it possible that its a caching issue? only possible if these are GET requests.

[perkiset]

Agree about the comm speeds - that was my first thought... but the evidence points to the packet never leaving the box at all... so if it's a dirty or collissiony net, then it'd be the card and drivers and OS... but in this case I'm talking several different versions of XP and one 2000 that I'm testing on. Hell, it even does it on IE 6 in XP running in Parallels on my Mac notebook - I though I'd exclude hardware as best I could.. think that pretty much cleared that one up.

@Cached: I don't think ajax requests are ever cached... could completely be wrong... but in any case, I always POST because the weird and unpredictable nature of the data that I (might) want to send home... and since I (might) need to POST I'd rather *always* post than mix it up.

Keep going bro - you're testing all the right stuff and perhaps we've just missed something...

[nutballs]

I just know that the XMLHTTPrequest object is fucked up in windows, unless you have been patched up. there are all kinds of security issues with earlier versions of xml3, xml4 is a total piece of shit, xml5 is just for office, xml6 is much better, but is a bit too security concerned so it gets in the way. For my serverside stuff(i know this is client but same difference) i keep trying to switch to xml6, but lordy does that not want to cooperate, so i just give up and go with xml3.

anyway the cache thing is just something i saw here:
http://en.wikipedia.org/wiki/Xmlhttprequest#Known_problems

but your POSTing, so its moot.

[perkiset]

anyway the cache thing is just something i saw here:
http://en.wikipedia.org/wiki/Xmlhttprequest#Known_problems

  interestingly I put a date-expires header on files by default, so I'd get away with it, but that is just SO WRONG. "I'm making a dynamic call to a back-end database for new information. But that's OK, you can cache it and forego new calls ... because you're omniscient."

Man sometimes I just don't know what the MS boys were thinking when they put that bastard together.

/p

[bluerose]

Okay guys, so here's what I can bring to the table. It's quite complex, but I'll do my best to state the facts in as clear a manner as possible.

I've got a tight set of requirements I can't really deviate from - I can't use any proprietary toolkits or external solutions that have not been "approved" for use. I can use Dojo Toolkit and Prototype, which are both JavaScript "libraries". I'm also using Struts (1.1) as the framework for this web application. I want to make it pretty and dynamic, so the obvious jump was "AJAX!" But we're stuck on an SSL network. I've run into some real doozies as far as debugging in the test integration environment goes...though development on my desktop has not shown any of those problems before deploying the appliation to the test integration environment (I'm going to abbreviate that as TIE from now on).

So Dojo provides a neat framework for sending asynchronous requests to the server. Two particular function calls are of note: dojo.io.bind() and dojo.io.FormBind(). The dojo.io.bind() call takes a map (of sorts) of arguments 'args', where 'args' is:
  {
     url:           'myStrutsAction.do',
     error:        function(type, error) {
                      alert('There has been an error: ' + error.message);
                    },
     mimetype: 'text/html',
     encoding:  'UTF-8',
     load:        myCallbackFunction,
     content:   params
  }

'params' is defined as an array of, again, "mapped" names and values which are the equivalent of sending request parameters to an action/servlet.

Now, the difference between FormBind() and bind() is this: bind() will immediately send an asynchronous request to the server, while FormBind() connects a form that you provide to the event of that form's submission. Instead of sending a normal POST to the server, Dojo's FormBind() allows the form to be sent via an asynchronous request to the server. FormBind, like bind(), accepts a variable 'args' defined as:
  {
     formNode:   document.getElementById('myStrutsForm'),
     mimetype:   'text/html',
     error:         function(type, error) {
                       alert('There has been an error: ' + error.message);
                     },
     encoding:   'UTF-8',
     load:         myFormSubmittedCallback
  }

Another thing to note here is I AM using Struts. This means for my Struts Form 'myStrutsForm', I have a validate() method which is called prior to the request reaching the Struts Action in question. If the validate() method returns errors, Struts is configured to return the input JSP (the page from which the form submit originated) AND to place the error message in request scope (ostensibly to be displayed on the page).

Now, myFormSubmittedCallback is going to receive an argument called 'data' which is the returned result (HTML) from the Struts Action. If the Struts Action (myStrutsAction) returns my generated HTML from the JSP with error messages embedded, then I know the form wasn't validated. And if the generated HTML returned has no error string in it, then I know the form was submitted, and those are the results that I want to display to the user.

HERE'S THE WEIRD THING (finally):
ONLY when the form is NOT validated do I get a funky IE6 SSL AJAX error (code 12030)! It works just fine every other time I've tried it...as long as the Struts Action gets to do its magic.

I've considered breaking down the form to use the dojo.io.bind() function instead, the form's myriad values being sent as request parameters...but I really would hate to break encapsulation and jerry-rig it like that. I've also considered making the form submission a simple, Web 1.0 form submit and refreshing the page...but I'd really hate to do that too since everything else that happens on that page is AJAX-ified.

Anyone here have any suggestions or comments? Did I explain all that well enough to be understood? I know it was LONG-WINDED!

Thanks, guys.

SAVE THIS DAMSEL IN DISTRESS, PLEASE! 

[perkiset]

Excellent explanation BRose, well done. Thoughts:

First off, I don't think that breaking out will do you any good. I am not using Struts or any other framework at all - I've hand rolled all of my stuff to be as lean as possible. The 12030++ errors are completely random for me. The only thing I have not tried (and I should be kicked for it) is GETting rather than POSTing, but since that is really just a teensy change in the header and placement of content I am hesitant to believe that it would have any affect.

I'm wondering though suddenly about some type of weird race condition in IE - it is well known, for example, that if you immediately try to access a document node (document.getElementById('anID')) at the document load time then it is a pretty good chance that IE will fail since the node has not yet had time to appear on the DOM tree. A simple sleep for even 10MS takes care of it.

What if the simple act of validating your form is enough code and time for the XMLHTTPRequestor to ... erm ... do "something" so that it is more stable when the request is thrown? I don't see quite yet how that fits in my scenario, but it might in yours - I create requestors at page load and then clear/reuse them as I need them, so I'm unclear on where a timing issue might come into play, but I'm intrigued. Perhaps even the act of clearing then setting the parameters on the XMLHTTPRequestor and immediately throwing the request is enough to confuse it sometimes - I don't have my arms around this yet but I am going to give it a good think and see if I can put together a test case tonight.

Welcome again, BTW - nice first post!
/p

[bluerose]

Thanks, perkiset - appreciate your input.

So that's one thing I should try - attempting with a GET instead of a POST...I'll let you know how that turns out.

I have to correct myself - I was able to get a (non-12030 but probably similar) error to pop up during a few form submissions that should have gone through. Although the frequency of this behavior is very low, I still am able to make the 12030 error pop up CONSISTENTLY during a form submission that fails its validate() method.

I really like your suggestion about the race condition in IE. That is a possibility. I wonder where I should put the timer, though. Though Dojo is open source, when I start sifting through the endless jibberish of JavaScript (implementation of XMLHttpTransport-supported AJAX framework) I start to feel a little sick to my stomach. I suppose I should ask that question of Dojo-gurus...or find it myself.

I'm wondering if I shouldn't try using a bind() instead of the FormBind()...I'm starting to pull up people's example code now, of submitting forms with Dojo's bind() function. I'll try that too and let you guys know how it goes.

In the meantime, keep your feelers out there for any other possible suggestions!

Thanks,

~BlueRose