Closed yifan closed 7 years ago
Don't you think it would be cleaner if the master only listens on one port, using either ws:// or wss:// (wss would be turned on if the certfile and keyfile arguments would be given)?
Just curious if this has been tested with chrome and found to work
On Thu, Nov 24, 2016, 2:58 AM Tanel Alumäe notifications@github.com wrote:
Don't you think it would be cleaner if the master only listens on one port, using either ws:// or wss:// (wss would be turned on if the certfile and keyfile arguments would be given)?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alumae/kaldi-gstreamer-server/pull/60#issuecomment-262712495, or mute the thread https://github.com/notifications/unsubscribe-auth/AIZyeAXEm8IMyJrdIycDi8titdyNcOfAks5rBUOzgaJpZM4K6y-b .
BTW, I just use nginx as a proxy to convert wss to ws, works with Chrome.
I was using one single port for ws:// or wss:// depending on command line option before. Then I didn't want to change my worker scripts, so I thought this works best to have compatibility of existing setup. It is true nginx will work just fine. This is just another option. Tested on Chrome and Edge.
I decided to go with the solution that I described: the server now uses SSL on the specified port if the keyfile and certfile options are specified. I committed the changes to master, largely based on this PR. @yifan, I hope this won't break your applications when you update your local repos, as I didn't use this port+1 method proposed by you.
@alumae the problem with that solution is when you have local worker node trying to connect with wss://localhost, I am not sure how the certificate works, since it is verified with a certain domain name. Maybe it doesn't matter.
I tested it and it worked for me (used a valid certificate for a outwards domain name, worker connected to localhost).
With this change, the server will listen to
port
andport+1
if--certfile
and--keyfile
are used. Normalws://
connection should use portport
, secured websocketwss://
will use portport+1
. This will get around the problem Chrome prevents user to send audio data to non-secure server.Usage:
master_server.py --certfile=fullchain.pem --keyfile=privkey.pem