WebSocketMessageReader vs Content-Length

[cdietrich]

is there a reason why WebSocketMessageReader/Writer does not support Content-Length header as StreamMessageReader/Writer and SocketMessageReader/Writer do? Not even Optional with a flag?

This implies that both server and client aggree not to need/ignore them. this wont work e.g. on LSP4J that easy.

[akosyakov]

1. This package is agnostic to an application protocol, i.e. to LSP.
2. jsonrpc + headers is only one possible transport for LSP: Why not use HTTP directly? microsoft/language-server-protocol#86 (comment)
3. content-length is redundant with web sockets and introduce string encoding/decoding overhead (performance)

LSP4J should be able to support different transports by replacing MessageConsumer and MessageProducer, e.g from StreamMessageConsumer to WebSocketMessageConsumer. If not please file an issue there.