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 <mshep...@openjdk.org> wrote:
>
> On Fri, 14 Mar 2025 10:11:29 GMT, Volkan Yazici <vyaz...@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
