OK here's a challenge:

Throwing a request from an XML ActiveX in Inte

rnet

  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

 


... of course this is in the middle of my own

ajax

 Requestor 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

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?

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.

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.

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

But as an aside, I've finally

learn

 ed how to both deal correctly with onerror and try/catch in JS because of this

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

net

 work 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

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

mac

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

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


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


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

net

 work that was the issue, or a busy

mac

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

interesting about the "other users on the same

net

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

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

I just know that the XMLHTTPrequest object is fished 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.

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

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

net

 work. 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! 

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 ap

pear

  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

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 sto

mac

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

Hey again BRose -

First, the 5 errors that I have listed with the exact same (or essentially same) conditions are 12029, 12030, 12031, 12152 and 12159. There is one other that happens occassionally that I do not have here, but these 5 are all the same.

Regarding FormBind and bind() I doubt that there would be a difference, if the way you describe it is understandable to me, because whether the initiation of the call is via the submit event on a document or by user/function call, the underlying code that executes the request would most likely be the same. But hell it is worth a try.

Although I am not enthusiastic, I am interested to hear if you get different results or even different symptoms with GET rather than POST. If this is true, it could be that we are looking in the completely wrong direction for the problem.

@Race: It may be a whole bunch easier for me to try the race stuff out because my code is really small, light and, cleverly, mine  - I have a pretty damn important application that needs this stuff and none-to-quick... so I'm going to see if I can work through some different ways of doing this tonight. I got a funny feeling in my sto

mac

 h when I was typing that post and that's usually a good thing... there's something here and I wanna get on the hunt. BTW, if you want to seem my requestor it is in the

Javascript

  code repository on this board. I change it up a bit, but that's essentially what I always use.

l8r,
/p

Hey all -

given yesterday's discussion I kludged together a mod of my

ajax

  requestor, but have put a 10ms delay between the 3 critical steps of dispatching the request... and as of yet, I have not gotten a single error - which is way out of normal for my testing.

I do not know if this is the deal yet, but I have a feeling that there is something here. I'll keep updating as I go.

The 3 critical steps I am seperating are:

    this.requestor.open('POST', theURL, true);

    this.requestor.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");   

    this.requestor.send(this.__postParams());

... these three steps are normally called in straight-ahead code... I'm doing a setTimeout between all three. I don't know what the sweet spot is yet (where I REALLY need the delay) but I will keep working. BRose - any progress on your side?

/p

OK here we go:

I've now got it down to the need for a slight delay between the open call and the send call. Here's my test:

I modified my code (several times actually, but this is the one I like) so that I do all of the prep work on the XMLHTTPRequestor in one function EXCEPT for requestor.send(). This last part of the execution I delay with a simple setTimeout by 10 ms. When I have it set this way, I executed about 200 calls and got zero errors.

So I undid everything to make sure this was an accurate test. In 100 clicks I got 8 errors, which is about my standard rate in testing. Another interesting feature of my test was that af first I was not getting as many errors - so I put up another couple browsers, one that is JS intense and let them continually refresh, which definitely made the occurence more frequent. I think I missed this before because I was not putting a JS hurt on the

mac

 hine... just a general processing hurt. I then re-implemented my changes but left the JS hurting browsers open and executed about another 100 calls and got zero errors again.

Unfortunately, this is simply science by vague observation, but it AP

PEAR

 S that it is much better, and given IE's threading mechanism (which messes up DOM placement as mentioned before) all of these symptoms would make sense.

I'm going to clean up the code now and repost in the JS repository for those using my code, and hopefully others (such as you BlueRose) will know where to poke in terms of tidying up the challenges you are facing.

Let's hope we got'er nailed!

/p

Notice: I have purposefully left the error checking (12030++) out of the new class because if it fails this way again, I want to know about it.

/p

Wow, Perkiset - impressive that you got such an amazing turnaround...so we think it's a timing thing, eh?

Unfortunately I did not get a chance to effect those changes I was talking about - working in a corporate environment so I can't just keep releasing my app to the Test Integration Environment continually...also getting some pressure from above to have a WORKING DEMO ready over the next two weeks, which means I won't be able to try anything, even your lovely solution, for two weeks. :-(

I took an hour to sift through the Dojo code for all instances of those three critical lines you mentioned, and surrounded those lines of code with a timeout. I know two weeks will effectively flush this issue from everyone else's mind, but unfortunately that's about the speed we move here. *Gri

mac

 e* I'll post back when I finally get a chance to try this out.

Thank you so much Perkiset! I'm glad YOU had an easily-accessible test environment to play with! :-)

I'll be around in the meantime, poking in every so often. Might migrate to other threads. Mayhaps to add some helpful hints where I can.

Again, thanks!

~Blue Rose

As you might notice from my last post, the problem is between

    this.requestor.open('POST', theURL, true);

and

    this.requestor.send(this.__postParams());

... doing everything EXCEPT the .send is OK - it seems to only have problems when I open then send immediately... if I open (and do or do not do anything else...) and wait 10ms it works out OK..

Hope you'll stick around BRose!

/p

One more update: I have found that, although I am now handling the 12xxx errors satisfactorily, the requestor still on occassion does not spit out the packets. I had timeout code in the original but it was not robust enough... so I've posted the

Ajax

 Requestor class yet one more time with bug fixes to make sure that if the packet never goes out (or an answer never comes...) then it correctly timesout, aborts and redispatches the request.

The default timeout in the class is 2500ms - which is the timeoutMS property. I've modified this now in a couple applications (like credit card processing) where that is clearly not enough - but in most cases that is more than adequate.

/p

Hmm...curious updates.

Well, I guess

programming

  would be for everyone if it were easy or made sense all the time!

I had the opportunity to spend a couple days at JavaOne this week, and tried to talk to Eugene Lazutkin (I believe he is someone who has worked on Dojo's codebase) about Dojo's

AJAX

  functionality and this issue. We didn't have enough time to go really in depth but he asked me to post it on Dojo's forum. I'll pretty much copy and paste my first post here, and maybe a couple of your replies (if you're okay with that) or else you can post stuff yourself on the Dojo forum, and hopefully he (or someone) will have some answers, or do some research on the issue.

In the meantime.............Google Web Toolkit. I wish to god I could use it here at work. I'm going to start pushing for it and see if I can't get it.

I LOVE GWT!!! More on that later when I start playing with it at home.

~BR

I'm fine with you posting @ Dojo that we're discussing it over here... but I'd prefer that you didn't simply copy my posts because they might not get the context in which I wrote them... please let them know that we'd love to have anyone over there that is interested to pop there head in over here.

@ GWT - Please let us know what you like/dont and keep us informed of your progress! Love to hear it, and I don't think there's anyone here that is currently deep into it.

/p

Try looking at my post in another thread, it might give you a bit of insight to the root cause of the problem and tips to work around it...

Post location changed - it is now the top of a new thread in the

Ajax

  Discussion area entitled More about the 12030 problem

OK, a few weeks/months later I returned to edit this simply because my initial 'found the cause' post turned out to be only partly correct - in the interest of tidying up after myself, I've since posted more info in another thread with some code to hopefully help those with this specific problem... Take a peek here instead:

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

ajax

 /xmlhttprequest_ie6_ssl_and_12030_error_what_is_the_solution-t442.0.html

I ran into similar issues with IE + SSL. Here's what I observed:

I would receive the 12030 stutus code about 50% of the time. I added "retry" code on in my onFailur method. This worked about half of the time.  Another chunk of the time, the request would take a long time to complete, but the server would receive the request, however the

PHP

  code did not receive the contents of the post.

I considered using an IFRAME instead, but decided to try placing my post data into the URL instead.  This works consistently and I haven't been able to reproduce the 12000+ error.

I don't get it, but so far so good.

-Michael

URL Clipped

Hello Michael and welcome to The Cache

Thank you for joining and your contribution - I must ask that you not post your URL here without consulting me first, thanks for your understanding.

Now back to our regularly schedule program:
I have not ever gotten past it. So I tell my clients that they must FireFox/Safari for my back office apps while I convert to the XRPC method I described here in another thread. And although I have continued to search, I have not yet found anyone that has a 100% fool proof answer.

Flippin' MS! Adjusting my stuff for IE is practically a career in itself...