<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">There is an rfc to disable the masking for TLS websocket connections <a href="https://www.ietf.org/archive/id/draft-damjanovic-websockets-nomasking-00.html">https://www.ietf.org/archive/id/draft-damjanovic-websockets-nomasking-00.html</a></div><div dir="ltr"><br></div><div dir="ltr">I’m not sure how much time I would spend refactoring this. </div><div dir="ltr"><br><blockquote type="cite">On Mar 14, 2025, at 10:17 AM, Mark Sheppard <msheppar@openjdk.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>On Fri, 14 Mar 2025 10:11:29 GMT, Volkan Yazici <vyazici@openjdk.org> wrote:</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>Fixes endian handling `jdk.internal.net.http.websocket.Frame.Masker`.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>### Implementation notes</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>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`.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Make method name changes backport-friendly</span><br></blockquote><span></span><br><span>persisting with method nomenclature (or painting the bikeshed again). What’s in a name?</span><br><span></span><br><span> reset is really init() or setMask()</span><br><span></span><br><span> Currently you have a static applyMask() method and a non static applyMask() — is that ideal ?</span><br><span></span><br><span> The Galloping mask methods, there has to be a more semantically meaningful name e.g. applyLongMaskRepeating or applyVectorMaskRepeating</span><br><span> (on your horse rather than on yer bike ;-)</span><br><span></span><br><span></span><br><span> I still think the following looking meaningful</span><br><span></span><br><span> public void applyMask(ByteBuffer src, ByteBuffer dst, theMask) {</span><br><span> if (src.order() == dst.order()) {</span><br><span> initLongVectorMask(src, dst, theMask);</span><br><span> applyLongVectorMask(src, dst, theMask);</span><br><span> }</span><br><span> endApplyMask(src, dst, theMask);</span><br><span> }</span><br><span></span><br><span>-------------</span><br><span></span><br><span>PR Comment: https://git.openjdk.org/jdk/pull/24033#issuecomment-2724999193</span><br></div></blockquote></body></html>