Bug in java.net.http.WebSocket (?)

[Fischer, Simon]

Hi all,

no idea if I am in the right place here, but I have no account to create a tracker issue and also could not find out how to get one...

I was just using the java.net.html.WebSocket (jdk17 specifically, but the issue should still be there at least in 21 from a quick look into the code) for testing purposes and stumbled upon what I think is a bug:

When I supply a _little endian_ ByteBuffer to WebSocket.sendBinary, the payload will be scrambled on the way to the server.

The actual issue is in jdk.internal.net.http.websocket.Frame. The loop()-portion of the transferMasking algorithm uses ByteBuffer.putLong(ByteBuffer.getLong) ("dst.putLong(j, src.getLong(i) ^ maskLong);") to try to optimize the masking and data transfer. Problem is that src is a ByteBuffer provided by the user, with the endianness set by the user, while dst is an internally allocated ByteBuffer with the default byte order. This obviously can lead  to 8-byte-blocks of the original message being re-ordered on the way to the client.

The solution IMO would be to ensure that both buffers are set to the same endianness. And it should probably be _native endian_, as the use of a specific endianness would likely render the long-vectorization/optimization useless on a machine which does not support that endianness natively (getLong would reverse the byte order when loading into native CPU register and putLong would reorder again). In that case, actually any case, care must also be taken with regard to the right encoding of the "maskLong" 64bit integer.

Alternatively, one could just adopt the documentation to require the ByteBuffer provided to WebSocket.sendBinary() to be default(/big)-endian encoded. Semi-solution IMO.

Would be interested in feedback and hope this finds somebody who can make use of it :)


Best regards
Simon Fischer

--
Simon Fischer

Developer
E5-CoDaC

Max Planck Institut for Plasmaphysics
Wendelsteinstrasse 1
17491 Greifswald, Germany

Phone: +49(0)3834 88 1215

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250305/37a58370/attachment.htm>