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

[Daniel Fuchs]

Hi Simon,

Thank you for the report.

I am not too familiar with WebSocket. But since this is
a networking protocol I would expect binary data to be
transferred on the wire in network byte order.

So the expectation from WebSocket::sendBinary that the
byte buffer is in network byte order (big endian) does
not seem unrealistic to me.

More concretely, since the API is there since java 11
(at least in its standard form), it would be difficult
to change this long standing behavior.

That said - a deeper analysis of the issue and possible
options is probably warranted. At least the expectations
should be documented.

best regards,

-- daniel

On 05/03/2025 17:53, Fischer, Simon wrote:
> 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 J
> 
> 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
>