flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From modjkl...@comcast.net
Subject Re: new Macbook and HTTP Request Errors for certain browsers
Date Thu, 13 Feb 2014 04:45:44 GMT
Hi Alex, I exported the project from the old machine, and imported into the new one, so everything
in it should be the same. The only thing that changed going to the new machine was changing
the name of one folder in the path where the project was imported to the new machine. Otherwise,
the flex code itself is the same. Regarding the fault event info, I see: 

event.fault.faultDetail="Error: [IOErrorEvent type="ioError" bubbles=false cancelable=false
eventPhase=2 text="Error #2032: Stream Error. URL: https://www.mycompany.com:443/myapp/login"]
. "URL: https://www.mycompany.com:443/myapp/login" 
event.fault.faultString="HTTP request error" 

I don't see anything else interesting. Is there some other info available I could obtain regarding
the fault, that might shed more light on it? 

----- Original Message -----

From: "Alex Harui" <aharui@adobe.com> 
To: users@flex.apache.org 
Sent: Wednesday, February 12, 2014 8:31:34 PM 
Subject: Re: new Macbook and HTTP Request Errors for certain browsers 

I'm not an expert in this stuff, but it appears the producer is generating 
a fault event. I think there should be useful information in that fault 

Also, are you sure the old machine was running the client in the same way? 
There's a big difference in running from file:// than http:// 


On 2/12/14 5:22 PM, "modjklist@comcast.net" <modjklist@comcast.net> wrote: 

>Thanks Alex, you are correct -- now I can retrieve the flashlog.txt file. 
>Here's what it is for Safari debug FP run using FB4.7 leading to "HTTP 
>Request Error": 
>'072C8379-78DJ3-D2EC-A600-289916442EDE' producer set destination to 
>'086B1D328F-D787-D581-D6F9-28AB96492F98' producer set destination to 
>'direct_http_channel' channel endpoint set to http: 
>'086B1D328F-D787-D581-D6F9-28AB96492F98' producer sending message 
>'direct_http_channel' channel sending message: 
>body = (Object)#1 
>userEmail = "user@mycompany.com" 
>userPwd = "mypassword" 
>clientId = (null) 
>contentType = "application/x-www-form-urlencoded" 
>destination = "DefaultHTTP" 
>headers = (Object)#2 
>httpHeaders = (Object)#3 
>messageId = "CCC89DCF-C521-8CA5-4642-28BD77875527" 
>method = "POST" 
>recordHeaders = false 
>timestamp = 0 
>timeToLive = 0 
>url = "https://www.mycompany.com:443/myapp/login" 
>'086B1D328F-D787-D581-D6F9-28AB96492F98' producer connected. 
>'086B1D328F-D787-D581-D6F9-28AB96492F98' producer acknowledge of 
>'086B1D328F-D787-D581-D6F9-28AB96492F98' producer fault for 
>Does that offer any hints? 
>Could cross-domain policy problems cause such a scenario for one browser 
>and not another? 
>My app uses RemoteObject with BlazeDS for HTTP access (e.g. 
>http://www.mycompany.com/ ...) on port 80, and HTTPService for HTTPS 
>access (e.g. https://mycompany.com/.. ..) on port 443. I'm not using any 
>crossdomain.xml file anywhere. I do have a proxy-config.xml file sitting 
>on my server WEB-INF/flex directory. It looks like: 
><?xml version="1.0" encoding="UTF-8"?> 
><service id="proxy-service" 
><adapter-definition id="http-proxy" 
>class="flex.messaging.services.http.HTTPProxyAdapter" default="true"/> 
><adapter-definition id="soap-proxy" 
><channel ref="my-amf"/> 
><destination id="DefaultHTTP"> 
>I believe this is the default proxy-config.xml file. I don't know if this 
>proxy-config.xml file is actually being used here by HTTPService (I 
>assume not, although the destination id="DefaultHTTP" makes me 
>suspicious), although BlazeDS certainly is for all http requests to the 
>Not sure if I'm on the right track or not with this. Seems like if this 
>is a cross-domain policy issue, I would have seen it the last couple 
>years when I was developing the app on my old machine, rather than now 
>when I'm transitioning to a new machine. 
>----- Original Message ----- 
>From: "Alex Harui" <aharui@adobe.com> 
>To: users@flex.apache.org 
>Sent: Wednesday, February 12, 2014 4:37:38 PM 
>Subject: Re: new Macbook and HTTP Request Errors for certain browsers 
>I thought the file was mm.cfg, not mms.cfg. 
>On 2/12/14 3:07 PM, "modjklist@comcast.net" <modjklist@comcast.net> 
>>I have a new Macbook OSX 10.9.1 and fresh installs of FB 4.7, and the 
>>nightly 4.12 SDK. 
>>I export my fully functional application from my desktop Mac, and import 
>>into FB 4.8 in the Macbook. 
>>From the new Macbook, I export a release build and place on the 
>>The app runs fine when I run it on the internet from my old desktop Mac 
>>(Chrome, Safari, Firefox). 
>>However, the NEW MACBOOK (which uses the same versions of Chrome and 
>>Firefox, but a newer Safari version) shows errors when accessing this 
>>from the internet, and when running from FB 4.7, as follows: 
>>**** PRODUCTION flash player, running app from WEBSITE **** 
>>Chrome -- works 
>>Firefox -- works 
>>Safari -- "HTTP Request Error" 
>>The Safari error occurs as soon as Safari communicates with the server 
>>(to log the user in) using the variable: 
>>private var _serviceSSL:HTTPService; 
>>**** PRODUCTION flash player, running app from FLASH BUILDER **** 
>>Chrome -- "Security error accessing url : Destination : Default HTTP" 
>>Firefox -- works 
>>Safari -- "HTTP Request Error" 
>>These errors occur at the same place discussed above for Safari. 
>>**** DEBUG flash player, running app from FLASH BUILDER **** 
>>Chrome -- works 
>>Firefox -- works 
>>Safari -- "HTTP Request Error" 
>>I tried to create a flashlog.txt file based on the article: 
>>I configured the mms.cfg file correctly as root, but while I have a path 
>>/Users/username/Library/Preferences/Macromedia/Flash Player/ 
>>there is no Logs folder here as the knowledge base article says there 
>>should be. Regardless, I run the app after cleaning, and compiling, and 
>>still no Logs folder is created. Then I manually create a Logs folder 
>>repeat and still no flashlog.txt file in the Logs folder. I must be 
>>something wrong to generate this log file. 
>>Anyway, I'm stuck here. Seems to be a security setting for my Macbook, 
>>interplay between Macbook and browsers, creating some problems. Any 
>>would be much appreciated. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message