On Tue, 25 Mar 2025 20:49:20 GMT, Chen Liang <li...@openjdk.org> wrote:
>> Volkan Yazici has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Add more tests
>> - Guard vectorization better
>> - Restore the old garbage-free state
>
> src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java
> line 201:
>
>> 199: final int srcLim = src.limit(), dstLim = dst.limit();
>> 200: int i = src.position(), j = dst.position();
>> 201: for (; i < srcLim && j < dstLim;
>
> I meant the endian issue is in this loop - the endianness of maskBytes
> (currently BE) must match that of dst (all internal usages of dst is
> currently BE). A safeguard would be nice here.
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 ?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24033#discussion_r2013101494
