chisel only speaks WebSocket today, so it can't connect through proxies or gateways that block or strip the Upgrade: websocket handshake (long-standing asks #24, #375; #507 is an example of chisel's transport blocked in the wild).
I've implemented an opt-in SSE+POST transport: a long-lived GET /sse for server→client, one POST /sse per client→server frame. It's --sse on the client, the server auto-accepts on /sse, and WebSocket stays the default. It reduces to a net.Conn behind the existing share/cnet seam (like conn_ws.go / conn_rwc.go), keeps chisel's single multiplexed SSH session, and adds no new dependencies (stdlib only).
I saw you built webdial with the same WS-primary / SSE+POST-fallback design. Would you prefer chisel's SSE built on webdial, or kept inline/stdlib? Happy to go either way; benchmarks and tests are ready.
chisel only speaks WebSocket today, so it can't connect through proxies or gateways that block or strip the
Upgrade: websockethandshake (long-standing asks #24, #375; #507 is an example of chisel's transport blocked in the wild).I've implemented an opt-in SSE+POST transport: a long-lived
GET /ssefor server→client, onePOST /sseper client→server frame. It's--sseon the client, the server auto-accepts on/sse, and WebSocket stays the default. It reduces to anet.Connbehind the existingshare/cnetseam (likeconn_ws.go/conn_rwc.go), keeps chisel's single multiplexed SSH session, and adds no new dependencies (stdlib only).I saw you built
webdialwith the same WS-primary / SSE+POST-fallback design. Would you prefer chisel's SSE built onwebdial, or kept inline/stdlib? Happy to go either way; benchmarks and tests are ready.