Skip navigation
Currently Being Moderated

Air app using URLLoader w/HTTPS fails on some Win7 computers but not others

Nov 15, 2011 9:40 PM

We have an Air app (SDK 4.5) which we are ready to deploy, but fails to connect via HTTPS URLs with error #2032 only on some Win7 computers but not others.

 

For troubleshooting, I can reproduce the problem using the simple test app example given in the AS3 URLLoader documentaton.

 

The issue is that when running the app on some Win7 boxes,  trying to connect to various servers via https and download a simple document, the request fails with "Error #2032".

 

The Air runtime version is 3.0 and we updated to 3.1 with the same result. The problem is related to HTTPS only- the same URLs work fine with HTTP.

 

Now for the fun: the same exact air app works fine on other Win7 box's, XP box's, OSX 10.6 and OSX 10.7 pointing at the same HTTPS URL's.

 

More fun: on  the Win7 boxes that fail, it only fails with some https URLs and not others, and the URLs that fail with this Air app on these certian win7 boxs work fine with the same air app on several other mentioned computers(XP, OSX and other win7).

 

I know that Error #2032 is a very generic "io error" and could be the result of many things, but in this case I have done some research to isolate what might be going on;

 

on the win7 boxes where the air app fails:

 

If we point the air app to a virtual host on our apache server setup with a self signed SSL cert, the air app pops up a panel saying the cert is not trused, and if we click "continue", we get the 2032 error and an http status code of 0. Apache never logs the request. This tells me that the air app is trying to negotiate an SSL session with the apache server, but never succeeds.

 

If we point the same air app to a virtual host on the same apache server setup with a REAL SSL cert, the air app never pops up the untrusted panel, but still fails with 2032 and http status code 0 returned.

 

If we point the same air app to a virtual host on the same apache server but HTTP instead of HTTPS, there is no failure and the request completes with a http status code 200.

 

Interestingly, If we point the same air app to various other HTTPS URLS on other hosts, both our servers and others on the internet that we know work, some fail the same way and some work fine.

 

NOW: If we run the same tests with this same air app, using the same HTTPS urls on other mentioned computers(XP, OSx and other win7), there is no failure and the request always completes just fine.

 

Another finding: you could theorize that there is something wrong with these win7 boxs, however the HTTPS URLs that fail with the air app, work fine on these boxes in IE and Chrome, also the same test app compiled as a Flex app and run in the browser on the machines that fail work fine with the same HTTPS URLs that fail with the air app, which to the air runtime having trouble on some win7 boxes.

 

This is a BIG problem for us, our Air app is a consumer app and will be deployed widely, and we can't have it failing to run only on certian computers and have no clue as to why.

 

Any help would be apprechiated.

 

Thanks,

Bob Reynolds

Software Engineer

EDT

 
Replies

More Like This

  • Retrieving data ...

Bookmarked By (1)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points