sonic182/aiosonic

Problem Only http and https proxies are supported. SOCKS proxies (Tor, SSH tunnels with ssh -D, corporate setups) can't be used. Today Proxy (aiosonic/proxy.py) speaks HTTP CONNECT (_proxy_connect in aiosonic/client.py). proxy_from_environment raises ValueError for socks5:// and other non-http schemes. Expected Proxy("socks5://user:pass@host:1080"), and the same from the environment, for socks4, socks4a, socks5 and socks5h (DNS resolved by the proxy), with TLS to the destination on top. Open questions Use an optional dependency (python-socks, which aiohttp-socks and httpx-socks use), or a small built-in SOCKS5 handshake? Done when Requests go through a test SOCKS5 proxy, with and without credentials, over http and https. Docs and CHANGELOG are updated.

Problem WebSocket messages are always sent and received uncompressed. That wastes bandwidth with servers that support permessage-deflate (RFC 7692), which most do. Today WebSocketClient.connect (aiosonic/web_socket_client.py) doesn't send Sec-WebSocket-Extensions, and frames are never compressed or decompressed. Expected Opt-in permessage-deflate: negotiate it in the handshake, honor client_max_window_bits and no_context_takeover, compress outgoing messages and decompress incoming ones, keeping the decompressed size of each message bounded, as max_decompressed_size does for HTTP bodies. References aiohttp ws_connect(compress=15). Done when Messages round-trip compressed against a test server, and a server that refuses the extension still works.

Problem start_keep_alive() (on by default in WebSocketClient.connect) sends pings, but when no pong comes back it just keeps going. A connection whose peer is gone (a crashed server, a NAT that dropped the mapping) stays "connected", and a receive_text() without a timeout waits forever. The OS may only notice minutes later. Today _keep_alive_loop (aiosonic/web_socket_client.py) waits for the pong with a timeout, and ignores the timeout. Expected When a pong doesn't arrive in time, the keep-alive closes the connection, sets connected = False, and pending and later receives raise ConnectionDisconnected. Reproduced With aiosonic 1.3.0 against a Node ws 8.18 server created with autoPong: false (it never answers pings), and connect(..., keepalive_interval=0.5): after 4 unanswered pings, connected is still True, the keep-alive task is still running, and receive_text(timeout=1) raises ReadTimeout instead of ConnectionDisconnected. References aiohttp ws_connect(heartbeat=...) closes the connec

Problem WebSocketConnection doesn't follow parts of RFC 6455 that servers rely on: Pings: a server that pings the client to check it's alive never gets a pong, and many servers then drop the connection. Close: when the server sends a Close frame, the client doesn't send one back. Fragmented messages: a message split into several frames loses everything after the first frame. If a text message is split inside a multi-byte character, decoding raises and the connection is dropped. Today _frame_dispatch_loop (aiosonic/web_socket_client.py) handles text, binary, pong and close frames. Ping frames are ignored, and continuation frames (opcode 0x0) fall through silently. _read_frame ignores the FIN bit, so each frame is treated as a whole message. On a Close frame, the loop only sets connected = False, and the server's close code isn't stored. Expected Answer each ping with a pong carrying the same payload (RFC 6455 §5.5.2). Reply to a Close frame and keep its code and reason (§5.5.1).

Problem Servers that use HTTP Digest authentication (RFC 7616), common on cameras, routers and some enterprise APIs, can't be used with aiosonic. Today Auth.apply(headers, method, url) (aiosonic/auth.py) runs once, before the request is sent. Digest needs a challenge and response: send the request, read the 401 and its WWW-Authenticate header, then send it again with credentials computed from the challenge. Event hooks can observe the 401 but can't resend. Expected A DigestAuth(username, password) that handles the challenge, with qop=auth, MD5 and SHA-256 (and their -sess variants), and the nonce count for reused nonces. Open questions Should Auth get a general "react to the response" step (like httpx's auth_flow generator) so other challenge-based schemes can reuse it? References httpx _auth.py (DigestAuth), aiohttp client_middleware_digest_auth.py. Done when DigestAuth works against a test server for each supported algorithm and qop. A body that can't be replayed fails clearly inste