nx_websocket_client_upgrade.nx

nx_websocket_client_upgrade.nx -- CLIENT-side WebSocket HTTP upgrade. Sibling to nx_websocket_upgrade.nx (server-side). Sends the HTTP/1.1 GET + Upgrade: websocket request on an already-connected TCP fd, reads the server's response headers, validates the 101 status, the Upgrade/Connection headers, and the Sec-WebSocket-Accept value against the SHA-1 + Base64 transform of the key we sent. RFC 6455 §1.3 + §4.1 + §4.2 client side. After this returns OK, the caller can use nx_websocket_stream's framer (just like the server side does post-upgrade). Request bytes built (CRLF line endings): GET <path> HTTP/1.1\r\n Host: <host>\r\n Upgrade: websocket\r\n Connection: Upgrade\r\n Sec-WebSocket-Key: <24-char base64 of 16 random bytes>\r\n Sec-WebSocket-Version: 13\r\n \r\n Response validation (RFC 6455 §4.2.2 + §4.1): Status-line MUST begin "HTTP/1.1 101" Upgrade: websocket (case-insensitive) Connection: Upgrade (case-insensitive, may be comma-list) Sec-WebSocket-Accept: <expected> (matches our key per §1.3 algo) Composes: nx_syscalls (sys_read / sys_write) nx_websocket_handshake (ws_accept = SHA-1 + Base64 of key||GUID) nx_rand (rand_bytes for 16-byte client key entropy) nx_base64 (b64_encode for the 16-byte key) Per Cardinals 9 (single-responsibility: ONE upgrade per call), 12 (defensive at boundary: every required header validated, status strictly == 101), 22 (composition over re-implementation: ws_accept is the authoritative SHA-1+Base64 transform), 14 (graceful degradation: distinct sealed-enum verdicts for each failure mode so caller can act differently on TIMEOUT vs BAD_STATUS).