Basic WebSocket Client Support in CLI

El issue no menciona archivos, pruebas ni puntos de entrada. Empieza localizando el despacho de esquemas de URL de la CLI y las rutas existentes de conexión y manejo de errores; después, sigue cómo se envía una solicitud y cómo se imprime su respuesta. Se considera terminado cuando ws:// y wss:// aceptan un mensaje de texto, imprimen un frame de respuesta, gestionan los fallos indicados y terminan limpiamente.

Checklist

• I've searched for similar feature requests.

Enhancement request

Add Basic WebSocket Client Support (ws://, wss://)

Introduce minimal WebSocket support to HTTPie CLI, allowing users to:

• Connect to a ws:// or wss:// endpoint
• Send a single text message via CLI argument
• Receive and print one response frame
• Exit cleanly

When a WebSocket scheme is detected, the CLI should establish a WebSocket connection instead of performing an HTTP request.

Example usage:

http ws://echo.websocket.events message="hello"

Expected behavior:

1. Establish WebSocket connection
2. Send the provided message as a text frame
3. Print the first received text frame
4. Exit successfully

Basic error handling should cover:

• Invalid WebSocket URLs
• TLS errors (wss://)
• Connection timeouts
• Unsupported/binary frames

This feature is intentionally scoped to provide minimal, non-interactive WebSocket testing support.

Problem it solves

I'm frequently testing APIs that expose both HTTP and WebSocket endpoints. While HTTPie works well for HTTP/HTTPS requests, I need to switch to another tool when validating WebSocket behavior.

I’m trying to test real-time endpoints quickly from the terminal so that I can verify message flow without leaving my CLI workflow.

Adding minimal WebSocket support would:

• Reduce context switching
• Improve developer productivity
• Make HTTPie more versatile for modern API development

Additional information, screenshots, or code examples

Proposed Scope Constraints

To keep the implementation focused and maintainable:

• No interactive REPL mode
• No continuous streaming session
• No advanced protocol extensions
• Single-message request/response flow only

Future enhancements (if needed) could extend this to streaming or interactive mode.

I would be happy to work on this enhancement and submit a pull request if the maintainers agree with the proposed scope.