next »

[Dragonlaird]

As I mention in the Ajax over SSL in IE 6 thread, this covers a small shitty where the requestor refuses to send out the packet

A few insights I've discovered whilst developing my own, cross-broswer AJAX object, sorry but I'm not posting the code guys - it's getting HUGE and spread over several files but...

The 12030 'bug' is not just restricted to SSL! It seems to occur whenever a port number is used in the URL. I can't confirm if this includes port 80 as to be honest, I haven't checked, but I can confirm it always heppens when I use a FULL URL complete with any non-standard port number, even if it is the same port as the host website.

A little pre-amble to help explain what I've discovered before offering a few tips to help get around the problem.

I found this same error when using the MS 'ASP.Net Development Server' on my local PC which fires up to load a site for testing/debugging purposes in programs such as VWD etc.

When this Dev Server loads, it uses weird and wonderful port numbers so as not to conflict with other ports already in use on the local PC (e.g. Port 80 is often assigned to Personal Web Server).

In my AJAX routines, I have a function which always converts the relative URL to the full, absolute URL. Simply put, this is a BIG mistake.

Use RELATIVE URLs people!

If your site is using Port 80 (or any other port for that matter) - and the URL you're posting to is in the same site, on the same port - don't try and get clever by converting the URL of the AJAX component to the full URL (complete with 'http://MySite/...').

If your site *must* use a port other than port 80, load the whole site using that port before you start using AJAX, then continue to use relative addressing for your all your AJAX URLs.

Don't try and load an SSL page (or any port number - even the SAME port as the website location) with an absolute URL via AJAX - It will die horribly in IE6+ with the dreaded 12030 error.

So, as a quick example of good/bad URLs to use:

If your base website address is:
http://localhost:1765
And you want to access, via AJAX, the page:
http://localhost:1765/Content/Default.htm
Do NOT use the above URL in your AJAX component, convert it to a relative address like:
/Content/Default.htm
Or:
Content/Default.htm
(The latter if you are calling the page from the ROOT of the site).

This causes a slight problem for everyone who's website intends to pass info over SSL when their base website uses Port 80. However, you *might* find it will work if you *always* load the base URL using 'https' instead of 'http'.

Not a perfect answer I admit, but hey - we're here to help each other so try it guys and let others know what you find!

[perkiset]

Great post Dragon... a couple adds -

I found inconsistency and even flat out failure with FF, Safari as well as IE when using fully qualified URLs - I never use them. I don't use relative URLs, I still use hard locations (ie., /adir/adir/afile.php as opposed to adir/adir/afile.php - note missing first slash which defines it as relative). The port number also is a problem, because by AJAX definition you are not allowed to change port, URL, subdomain, or even protocol... the call must go directly to the exact same place it came from or it is out of standard. Interestingly, it seems that in IE6 you can sometimes get away with it - this is actually a bug.

So what's a poor ajaxxer to do?

I'm working on an iFrame remote scripting call/receive class that mimics AJAX, but is much more stable do to the more widely accepted standards of iFrames and standard HTML. Additionally, this has the benefit of being able to grab from any other port or protocol... or even to another domain, which in a large application I am working on, this is critical. Personally, I am moving back towards the notion of simple "Remote Scripting" than really ajax, since I don't always use XML as my communication syntax/structure, and if I blend in iFrame remote procedure calls instead of using the XMLHTTPRequest then, of course, I am heretical.

I'll be posting it in the next many days when I get it done - I think it will spin your gears a bit.

/p

[perkiset]

<slightHijack>
Wait now...

Am I being incredibly stupid? Isn't the notion of a mashup a combination of things from different websites? If I call for javascript from another domain, can't functions in that javascript call home to that domain? Isn't this exactly how the Google Maps API works? Suddenly feeling like a big cool train has been driving by me and I haven't been hearing it...

</slightHijack>

[nutballs]

YES. the "remote" domain has to have functions that do what you want of course... simple example. I can have a cool crazy flyout menu on my site, without hosting the JS... i know what your thinking...

[perkiset]

Oh yeah... stayed up late on the notebook and demo'd it. How'd I fishing miss that?!?!?! Given the SSL/12030 success I've had, I'm thinking hard this morning about where I'm going with ... that... let you know prolly later today or tomorrow.

/p

[artur.chyzy]

We would like to contribute some more info with regard to 12030, 12151, 12031 errors in IE6. We  have got these problems in our application and went almost mad due to the problems.



The solution which we found is to force HTTP protocol version to be downgraded to 1.0 from default 1.1.

It seems that our beloved, commonly known and highly qualified vendor of Internet Explorer, has implemented HTTP 1.1  vary badly.

In our case this workaround has helped and we don't get the errors any more.



This can be done in Apache configuration:

SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0



Let us know if it worked for you.



Artur

[nutballs]

what would be the downside to doing that? For the most part, that seems like a reasonable, albeit stupid to have to do it, solution.

[perkiset]

Welcome Artur -

Thats a really novel solve and I can't seen any downside really... it would be very easy to set the environment to 1.0, then rewrite the URL into a handler if it is an AJAX call, then set the environment back to 1.1 right after the rewrite if it even gave you trouble... although I am not sure what trouble it would give.

Artur did you notice any other symptoms or side-affects of downgrading the HTML version?

BTW - great work and really creative. Never would have even thought of that or tried it. Well done.

/p

[artur.chyzy]

Well tkanks.
But this not all my job.
I was using wireshark to track the tcp packets.
The were some problems with SSL connection on packets level (wrong checksum)
My friend found on some site that there are some problems with HTTP 1.1 with IE.
We decided to try do downgrade it do 1.0
What was my suprise when this actually worked (so remember not to fight with IE alone )

Also the problem is does not apper on IE7 .. probably MS reimplemented SSL

[artur.chyzy]

Oh,, and also the downside.
I'm not an expert but this would be only downside beetween HTTP 1.1 and 1.0
No keep alive
Each image, js or sth else need to be downloaded by browser in separated connection
So this would be a litte bit slower but not so much (i didn't do any performance tests)
But also on pages which shows config for apache and ssl they say to downgrade MSIE to 1.0 because od bug in the IE
Even if this would work correctly other things would not
So for me downgrade SSL on IE to HTTP 1.0 is the default

[kidplug]

I just came across this thread while looking for info on the SSL errors (12152 etc) in IE6 using ajax calls.

I built a retry into my ajax routine in order to deal with these, and everything works fine on the client side.

However, I have recently noticed that I am getting alot of server side errors which I believe are related.

It looks like when the client gets one of these errors and then immediatley retries - my server actually does get both requests.
The first request is the "bad" one, and the second one is handled successfully.

Five minutes later tomcat gets a "Short Read" exception in the thread handling the first request.

So, it would seem that the original failed request has been tying up a resource on my server for five minutes.

My question is - would calling abort() on the xhr before doing the retry sever the connection to the server?
I am going to try this, but I wondered if any one else has observed the same thing.

Thanks.

[perkiset]

I don't think it would hurt at all, and certainly is a good protocol.

Interesting that TomCat saw the request - in PHP I don't get one. I'm wondering if Apache sends things more immediately to TomCat (like the moment a header or partial packet comes in) rather than bundling the entire mess up and shipping it off to the PHP instance as one complete packet... in other words, if IE doesn't send it all, then Apache hears it but not PHP. ( QQ: Are you going straight into Java or using JBoss or something on the back end under TomCat? And I'm assuming that programmatically you never see it, you just see the logged error? )

Then it would be holding up handles on the server, you're correct.

So an abort() would be a good option because presumably Apache would hear *that* - but since the communcation layer seems to have been disrupted, I'm wondering if anything further would get through to Apache, even the packet-layer notification of an abort...

I've posted my personal code in the Code Repository, under "Ajax Requestor Class" - the solve I got for this was to setTimeout to fire the request - so I delay about 10ms before firing it off, which completely eliminated my troubles. It might be worth a look for you.

Thanks, and welcome to The Cache BTW!
/p

[StephenBauer]

Doesn't using HTTP 1.0 yield no host headers?  If I recall, it does not.

May need to account for the lack of a host header if you are doing any virtual domain hosting or re-writing based on host/domain name.

SB

[StephenBauer]

<slightHijack>
Wait now...

Am I being incredibly stupid? Isn't the notion of a mashup a combination of things from different websites? If I call for javascript from another domain, can't functions in that javascript call home to that domain? Isn't this exactly how the Google Maps API works? Suddenly feeling like a big cool train has been driving by me and I haven't been hearing it...

</slightHijack>

Everything is sub-domained at Google for the most part. 

SB

[kidplug]

Thanks for the reply, perk.

I am running apache in front of tomcat - and apache actually doesnt log anything until five minutes later, presumably when tomcat has errored out and given its response back to apache.  That is probalby a function of the logging level - apache is probably capable of logging something immediately.

My servlet in tomcat is getting called - the doPost() method that is, since these all seem to occur for me on Post.
So my servlet code is being executed.  The exception occurs when actually trying to read the incoming request object.  It sits there for five minutes then throws the exception.

Interestingly, I have found that these errors are occuring (not as often) on non-ajax requests as well - meaning on other "regular" post requests from the browser.  IE itself is probably handling the retry in those cases.  I guess this IE6 SSL / keep-alive bug is at the heart of this problem.

My retry call is also done (like yours) via a settimeout() and it does work fine on the client.

I'm trying to reproduce the problem right now so i can test if the abort() helps, and of course the problem wont happen for me!