<div dir="auto"><br></div><div dir="auto"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 27, 2026 at 9:27 AM Artur Barashev <<a href="mailto:abarashev@openjdk.org" target="_blank">abarashev@openjdk.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Tue, 27 Jan 2026 16:54:28 GMT, Xue-Lei Andrew Fan <<a href="mailto:xuelei@openjdk.org" target="_blank">xuelei@openjdk.org</a>> wrote:<br>
<br>
>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:<br>
>> <br>
>> Allocate 24 bits for input size in cache key. Add unit tests.<br>
><br>
> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 982:<br>
> <br>
>> 980: boolean enableCertificateCompression) {<br>
>> 981: this.enableCertificateCompression = enableCertificateCompression;<br>
>> 982: }<br>
> <br>
> Is there a plan to support brotli compression algorithm in OpenJDK? It is the only supported algorithm in browser Chrome.<br>
> <br>
> If there is a need to support more than one compression algorithms in the future, it might be better to provide an option to customize the algorithms selection, including preferences. The flexibility could provide better interoperability if a vendor does not support compression algorithm properly.<br>
<br>
Yes, strangely Chrome supports only brotli although I didn't see any difference in compression ration between zlib and brotli when manually testing certificate compression. We may add support for more algorithms in the future, but for now it's zlib only.</blockquote><div dir="auto"><br></div><div dir="auto">Once there is a need to support more algorithms, this API may not be applicable for some cases especially when there are compatibility impact. It might be good to consider the API to support multiple algorithms from day zero.</div><div dir="auto"><br></div><div dir="auto">Just my $0.02.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Xuelei</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
Generally speaking, it's the certificate's metadata that is being compressed, the keys are high-entropy data difficult to compress. PQC certificates don’t compress well, most likely because of lower metadata to keys ratio.</blockquote><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
<br>
-------------<br>
<br>
PR Review Comment: <a href="https://git.openjdk.org/jdk/pull/28682#discussion_r2733079369" rel="noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/28682#discussion_r2733079369</a><br>
</blockquote></div></div>