> > Just one minor comment; in: > > http://code.google.com/p/socketio-java/source/browse/src/com/glines/socketio/server/transport/FlashSocketTransport.java > > Start flash policy server isn't going to overcome the issue with the > default policy port being 843, and thus < 1024 requiring root to bind > that port (handily ignored by: > if (flashPolicyServerHost != null && flashPolicyDomain != null && > flashPolicyPorts != null) { try { startFlashPolicyServer(); } catch > (IOException e) { /* Ignore */ } } > > Not that much of an issue since I guess you just fail over to another > method, but it does mean flash basically just won't get used as a > transport in the majority of cases; I never followed up doing that as > part of the websocket stuff I did because I don't think it's really > the right answer. >
Some one mentioned modifying the Flash code so that an alternate policy port could be specified. That plus the fact that the policy port can be configured in FlashSocketTransport should be a reasonable fix. > Really the solution is for the server to respond to an auth XML > request on the websocket port, but that requires the websocket > listener on the server side to handle a special xml auth request code > as a special case, which is annoying. Had any thoughts on that front? > There are two ways this could be handled. One is to patch jetty so that non HTTP requests are dispatched to a different handler. The other is to write a bit of code that listens on the main port (e.g. 9898, checks for the policy request and either handles it or proxies the whole connection internally to a hidden port that the server listens on. I'd prefer the first since the second is hackish. -Tad -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
