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

[Robert Engels]

There is an rfc to disable the masking for TLS websocket connections https://www.ietf.org/archive/id/draft-damjanovic-websockets-nomasking-00.html

I’m not sure how much time I would spend refactoring this. 

> On Mar 14, 2025, at 10:17 AM, Mark Sheppard <msheppar at openjdk.org> wrote:
> 
> On Fri, 14 Mar 2025 10:11:29 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:
> 
>>> Fixes endian handling `jdk.internal.net.http.websocket.Frame.Masker`.
>>> 
>>> ### Implementation notes
>>> 
>>> I deleted the `Frame` clone in tests, and rewired the test code depending on it to the actual `Frame`. To enable this, I relaxed the visibility of the actual `Frame`. I guess the `Frame` clone was introduced to have strict visibility in the actual `Frame`. Though this is not needed since the actual `Frame` is in an internal package. Plus, the fact that bug is in the `Frame` class hints in the direction that there should be one `Frame`.
>> 
>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  Make method name changes backport-friendly
> 
> persisting with method nomenclature (or painting the bikeshed again). What’s in a name?
> 
>    reset is really init() or setMask()
> 
>    Currently you have a static applyMask() method and a non static applyMask() — is that ideal ?
> 
>   The Galloping mask methods, there has to be a more semantically meaningful name  e.g. applyLongMaskRepeating or applyVectorMaskRepeating
>    (on your horse rather than on yer bike ;-)
> 
> 
>  I still think the following looking meaningful
> 
>        public void applyMask(ByteBuffer src, ByteBuffer dst, theMask) {
>            if (src.order() == dst.order()) {
>                initLongVectorMask(src, dst, theMask);
>                applyLongVectorMask(src, dst, theMask);
>            }
>            endApplyMask(src, dst, theMask);
>        }
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/24033#issuecomment-2724999193
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250314/1ca06c52/attachment-0001.htm>