Well, if you're not controlling the backend of port 80 then that's a
different story entirely. I thought that you were only using port 80
because of firewall restrictions, but I didn't know you also didn't want
to control the backend of port 80 too. Are you really just trying to do
push over HTTP?

________________________________

From: [email protected] [mailto:[EMAIL PROTECTED] On
Behalf Of Matt
Sent: Wednesday, April 18, 2007 2:04 PM
To: [email protected]
Subject: [flexcoders] Re: Socket to Port 80



If I'm understanding the way the xmlsocket:// protocol works properly
then I believe this is problematic. With a Socket connection I'm able
to connect back to the web server on the same port because I fulfill
the HTTP request requirements to get me where I want. However, it
looks as though xmlsocket:// requires an arbitrary communication
protocol via XML, not HTTP. Is that correct?

My primary purpose in wanting to establish a connection to the server
via port 80 is so I don't have to worry about Firewall issues for
clients since they already had to connect to port 80 to get the SWF
file. It doesn't look like there's any way for me to get the
xmlsocket:// connection to communication via HTTP is there?

Sorry for the complex requirements, but if I can jump this hurdle this
will make for a very nice communications system.

Thanks again.

--- In [email protected] <mailto:flexcoders%40yahoogroups.com>
, "Peter Farland" <[EMAIL PROTECTED]> wrote:
>
> I did a little more digging, and despite the way that sentence reads
in
> the documentation for securityError, this port limitation is not
> actually independent of security sandbox policies and can be avoided
> with the correct policy settings.
> 
> Take a look at the documentation for the connect() method:
> 
> http://livedocs.adobe.com/flex/2/langref/flash/net/Socket.html#connect
<http://livedocs.adobe.com/flex/2/langref/flash/net/Socket.html#connect>
()
> 
> It appears that you can specify a policy file for ports less than
1024,
> but it can only be done via the method I mentioned via responding to
the
> <policy-file-request/> token and it appears that despite that you're
not
> explicitly using an XML socket, for the purposes of locating a policy
> file you do use the xmlsocket://myserver <xmlsocket://myserver>  as
the protocol in the URL to
> loadPolicyFile.
> 
> Pete
> 
> 
> 
> ________________________________
> 
> From: [email protected] <mailto:flexcoders%40yahoogroups.com>
[mailto:[email protected] <mailto:flexcoders%40yahoogroups.com>
] On
> Behalf Of Paul DeCoursey
> Sent: Wednesday, April 18, 2007 12:16 PM
> To: [email protected] <mailto:flexcoders%40yahoogroups.com> 
> Subject: [flexcoders] Re: Socket to Port 80
> 
> 
> 
> --- In [email protected]
<mailto:flexcoders%40yahoogroups.com>
<mailto:flexcoders%40yahoogroups.com>
> , "Peter Farland" <pfarland@> wrote:
> >
> > 
> > > I'll give this a try, but I'm not actually using
> > > XMLSocketbut a straight Socket ...
> > 
> > [Pete] I did see that, but was looking around at samples for loading
> > custom policy files over a socket and must have cut and pasted one
> that
> > included the xmlsocket: in the protocol. But protocols aside, I
think
> > the next paragraph explains your issue and it is not related to
policy
> > files at all...
> > 
> > 
> > 
> > > 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.
> > 
> > [Pete] Ah, yes, you're right. It is listed as an explicit security
> error
> > in the documentation if one attempts to connect to a port less than
> > 1024. From my reading of this documentation it is mentioned as a
> > restriction independent of any security sandbox policies.
> > 
> > 
> 
> Although this is no help, I just thought I would chime in with a
> rant... Why can't we open a socket on a port lower than 1024? I would
> understand if it were to open a ServerSocket but these are sockets. 
> Although we can use proxies or install our services on higher ports,
> which will probably be blocked by firewalls in the real world I find
> this limiting. I'm sure this is all because of plugin/browser
> limitations, and it probably makes sense to some "nerd" somewhere.
>



 

Reply via email to