fastapi_websocket_rpc
fastapi_websocket_rpc copied to clipboard
No support of http_proxy https_proxy
The framework uses websockets module (here).
The websockets module does not support HTTP proxy (see https://github.com/python-websockets/websockets/issues/364, issue from 2018), while websocket-client module (here) supports it.
Are they plans to migrate websockets implementations though websocket-client instead?
Hi @antoinetran - no such plans at the moment.
We would be willing to review a PR, if you'd be interested in contributing such a feature. I would also recommend to look at adding an option of using these other websocket implementation and toggling it with a flag, rather than outright migrating
Ok I will give a try, although I am not an Python expert. I saw that the fastpi websocket use lots of coroutine, but the websocket-client is not written in coroutine (see https://websocket-client.readthedocs.io/en/latest/threading.html#asyncio-library-usage). I will see what I can do.
Ok, I tested a bit and it seems to work! Will do a PR, with a class parameter to choose which Websocket client implementation. By default, it should be the websockets, because it is natively coded as coroutine, but I will ship another class that implements SimpleWebSocket using websocket-client.
I am not sure if my implementation is optimal.
I will also add websocket-client as an dependency of this framework and modify the README a bit to show how to change the implementation to use proxy.
@antoinetran Hey, I've created a patch for websockets to use with proxy servers: https://github.com/racinette/websockets_proxy
@antoinetran Hey, I've created a patch for websockets to use with proxy servers: https://github.com/racinette/websockets_proxy
Nice! You are free to provide your own websocket client handler to fastapi websocket rpc, in for example your module. But for now, I would rather stick with the official websocket client, and in the future, only the websockets, when their team will fix support of http proxy.