Jason G. commented out XNIO-222 to see the spec about the content-lenght.
I found this:
Each SIP message MUST be carried within a single WebSocket message,
and a WebSocket message MUST NOT contain more than one SIP message.
Because the WebSocket transport preserves message boundaries, the use
of the Content-Length header in SIP messages is not necessary when
they are transported using the WebSocket subprotocol.
This simplifies the parsing of SIP messages for both clients and
servers. There is no need to establish message boundaries using
Content-Length headers between messages. Other SIP transports,
such as UDP and the Stream Control Transmission Protocol (SCTP)
[
RFC4168], also provide this benefit.
It was fixed, so the previous problem it is not present anymore:
This was replaced:
339 return;
340 }
by that:
private void handleUpgrade(final HttpUpgradeParser parser) {
Map<String, String> simpleHeaders = new HashMap<>();
for(Map.Entry<String, List<String>> e : parser.getHeaders().entrySet()) {
simpleHeaders.put(e.getKey(), e.getValue().get(0));
}
final String contentLength = simpleHeaders.get("content-length");
if (contentLength != null) {
if (!"0".equals(contentLength)) {
future.setException(new IOException("Upgrade responses must have a content length of zero."));
return;
}
}