RFR: 8351339: WebSocket::sendBinary assume that user supplied buffers are BIG_ENDIAN [v7]

[Michael McMahon]

On Wed, 26 Mar 2025 00:21:02 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> should the Endian check be in the genesis of the processing i.e. the applyMask method ?
> 
> ```
>     static void applyMask(ByteBuffer src, ByteBuffer dst, int mask) {
> ```
> 
> // endian check here then other checks are superfluous ?
> 
> ```
>         if (src.remaining() > dst.remaining()) {
>             throw new IllegalArgumentException(dump(src, dst));
>         }
>         new Masker().setMask(mask).applyMask(src, dst);
>     }
> ```
> 
> Additionally, if the WebSocket spec (RFC 6455) expects that data is sent (received) in network byte order (Big Endian), then both src and dst should be ByteOrder.BIG_ENDIAN rather than just the same byte order ?

A stream of data bytes is just a stream of bytes. The big/little endian question only comes into it when you try to interpret bytes as 32 bit (or 64 bit) integers, and that's only an implementation artifact, supposedly to optimize performance. All this code relating to byte order would disappear if we removed this "optimized" code path.

Afaict, the RFC refers to byte order itself only for framing data that is itself 16 bit or 32 bit. The payload length is encoded in network byte order but application data is just a stream of bytes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24033#discussion_r2013586618