[Feature Request] Expose public WebSocket proxy/connect options on ws.Client
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- python
- Área
- networking
Línea de trabajo
Lee lark_oapi/ws/client.py alrededor de _ws_connect_kwargs() y la llamada a websockets.connect(), y luego sigue cómo obtienen sus argumentos las conexiones iniciales y las reconexiones. Define la configuración pública del proxy por Client para los comportamientos de valor predeterminado solicitado, entorno, deshabilitado y proxy explícito, y verifica que ambas rutas de conexión usen la misma política sin depender del helper a nivel de módulo.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
English
Problem
lark.ws.Client currently forces a direct WebSocket connection on websockets 15 by returning {"proxy": None} from the private module-level helper _ws_connect_kwargs():
The result is passed to websockets.connect() here:
This preserves the SDK's historical direct-connect behavior, but applications whose outbound traffic must use an HTTP/HTTPS/SOCKS proxy have no supported way to let the event WebSocket honor HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY.
This is specifically about the long-lived event WebSocket. It is separate from HTTP API proxy support discussed in #82.
Current workaround
Applications must monkeypatch the private global helper:
import lark_oapi.ws.client as ws_client
# Let websockets 15 use its normal environment proxy discovery.
ws_client._ws_connect_kwargs = lambda: {}
One real-world adapter is here:
https://github.com/ZichaoLong/focus/blob/main/bot/feishu_ws_proxy.py
This workaround is fragile across SDK updates and process-global, so it cannot safely configure different Client instances independently.
Requested public API
Please expose a supported, per-Client way to configure the arguments or proxy policy used by websockets.connect().
Possible API shapes include:
lark.ws.Client(..., ws_proxy="env") # honor proxy environment variables
lark.ws.Client(..., ws_proxy="disabled") # force a direct connection
or:
lark.ws.Client(..., ws_connect_kwargs={"proxy": True})
The exact API shape is up to the maintainers. The important properties are:
- The existing default remains unchanged for backward compatibility.
- Configuration is per client instance, not a module-level global.
- The same policy is used for initial connection and reconnects.
- Environment proxy discovery, explicit proxy disabling, and ideally an explicit proxy URL can be represented.
- Callers no longer need to depend on
_ws_connect_kwargs.
Environment
- Latest PyPI release observed:
lark-oapi 1.7.1 - Also reproduced with:
lark-oapi 1.6.4 websockets 15.x
中文
问题
lark.ws.Client 当前会通过私有的模块级函数 _ws_connect_kwargs() 返回 {"proxy": None},从而在 websockets 15 下强制 WebSocket 直连:
返回值随后在这里传给 websockets.connect():
这一行为保留了 SDK 历史上的默认直连语义,但如果应用的出站网络必须经过 HTTP、HTTPS 或 SOCKS 代理,目前没有公开且受支持的方式,让事件 WebSocket 遵从 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY。
本 issue 只讨论长连接事件 WebSocket,与 #82 中的 HTTP API 代理支持是两个不同问题。
当前 workaround
应用目前只能 monkeypatch 私有的全局函数:
import lark_oapi.ws.client as ws_client
# 让 websockets 15 使用正常的环境变量代理发现行为。
ws_client._ws_connect_kwargs = lambda: {}
一个实际使用中的适配实现见:
https://github.com/ZichaoLong/focus/blob/main/bot/feishu_ws_proxy.py
这种方式依赖 SDK 私有实现,升级时容易失效;而且修改的是进程级全局状态,无法安全地为不同 Client 实例设置不同代理策略。
希望提供的公开接口
希望 Client 提供一个受支持、按实例生效的公开接口,用于配置传给 websockets.connect() 的参数或代理策略。
可能的接口形式例如:
lark.ws.Client(..., ws_proxy="env") # 遵从代理环境变量
lark.ws.Client(..., ws_proxy="disabled") # 强制直连
或者:
lark.ws.Client(..., ws_connect_kwargs={"proxy": True})
具体 API 形式由维护者决定。希望它至少满足:
- 默认行为保持不变,避免破坏现有调用方。
- 配置属于单个
Client实例,而不是模块级全局状态。 - 首次连接和后续重连使用相同策略。
- 能表达环境变量代理发现、显式禁用代理,最好也支持显式代理 URL。
- 调用方不再需要依赖私有的
_ws_connect_kwargs。
环境
- 当前观察到的 PyPI 最新版本:
lark-oapi 1.7.1 - 同样复现于:
lark-oapi 1.6.4 websockets 15.x
- Lenguaje dominante
- Python
- Estrellas
- 559
- Forks
- 102
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de larksuite/oapi-sdk-python
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
larksuite/oapi-sdk-python#163 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
larksuite/oapi-sdk-python#162 · 1 comentario ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 94/100
larksuite/oapi-sdk-python#161 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
larksuite/oapi-sdk-python#160 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
larksuite/oapi-sdk-python#159 ·
Todos los issues de larksuite/oapi-sdk-python
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100