-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build in reverse proxy or other solution for not requiring two ports #142
Comments
I had success running ShinySDR behind a nginx reverse proxy using just one port for exposing both the HTTP and the websocket endpoint. The trick is to use a path-rewrite to dispatch the requests: Assuming HTTP runs on 8100, websocket on 8101: shinysdr:
nginx site:
This setup can further be used to add SSL, but there careful tuning is necessary to achive low latency:
The only issue is that when using SSL I regularly run into issue #125 during startup of the web-gui in Chrome. However, when the startup is successful, everything runs smooth. In Firefox, this issue does not appear. |
Thanks for the info! May I have your permission to incorporate that nginx configuration as a template into ShinySDR under ShinySDR's GPL license? (I'm asking explicitly because it's not in the form of a pull request and I'm not sure whether that counts for the automatic licensing in GitHub's TOS.) |
Hi @kpreid, |
The requirement to configure two server ports is occasionally problematic. It would be nice if we could eliminate it. Options:
Migrate WebSocket server code from txWS to Autobahn, another Twisted library which integrates WebSockets and HTTP instead of requiring separate transports. I made some attempt at doing this in https://github.com/kpreid/shinysdr-morgue/tree/autobahn but was stymied by various cases of unhandled errors being silently discarded as I attempted to migrate the code.
Launch a reverse proxy as a subprocess, configuring it to talk to autoassigned local ports, so that the user only needs to specify the single port they want. (Supporting reverse proxies at all was issue Allow specifying root URLs separately from endpoints #92.)
This issue will probably be about the second option.
The text was updated successfully, but these errors were encountered: