I'll give this a try, but I'm not actually using XMLSocket but a straight Socket (and I wrote code in ActionScript to send an HTTP post header and a Servlet to process the input and then begin the streaming of data). Do I need to pass a different protocol for a straight socket?
I've been baffled by the reason that connecting back to the exact same host and port that the SWF came from would have security limitations but I believe I remember reading something about that in the Flex documentation that it has to do with it being a Socket connection to a port under 1024. Thanks for the response and I wasn't trying to seem ungrateful for lack of response from Adobe, just frustrated that I can't seem to get my problem solved. :) --- In [email protected], "Peter Farland" <[EMAIL PROTECTED]> wrote: > > > I am trying to use ActionScript (in Flex) to communicate back to the > HTTP server that the SWF was loaded from on port 80 using a Socket. If > my server is running from port 8080 everything works fine, but when > it's on port 80 I get a sandbox violation. > > [Pete] For Sockets, I think you need to load a policy file from the > socket itself... in the loadPolicyFile call you set the URL to > "xmlsocket://localhost:80". You scan the input on the socket to see if > you're being sent an XML line of <policy-file-request/>, in which case > you need to reply with the policy file XML content. > > The part I don't quite get is why you'd need to do this if you've loaded > the SWF from the same port, but perhaps either sockets and the general > SWF loading mechanism are seen as independent security sandboxes or that > the fact you specify an explicit port "80" for the socket but not for > the URL that loaded the SWF that the domain:port is seen as being > different. > > > > I posted on the Flex forums at Adobe, but I never got any response and > heard you guys were much more knowledgeable, so I hoped you could help. > :) > > [Pete] I (and several other Adobe engineers) reply to flexcoders when we > have the time because new postings appear as individual emails which are > easy to scan, can be searched, can be organized into threads without > waiting for pages to reload etc, and it's as simple as clicking on reply > to post a response (no login screens, no forms to scroll through). Web > based interfaces for forums just aren't convenient for this sort of > quick interaction IMHO. >
