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
