On Wed, 26 Mar 2025 00:21:02 GMT, Mark Sheppard <mshep...@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
