Hi Martijn, Thank you for this FLIP. I ran into this while upgrading flink-kubernetes to use Fabric8 7.3.1, and overall I agree with the motivation of removing OkHttp/Okio.
For the JDK HTTP client, I agree with Zhe that the JDK version requirement should be very obvious to the users, but I don't think everyone reads release notes. My advice would be to add a runtime check to the Kubernetes client factory that checks the actual JDK version, and fail the application upon startup if the JDK version is < 11.0.19. On the rejected alternative of Vert.x, I think the pulled dependency of Netty stack could be easily shaded and relocated to `org.apache.flink.kubernetes.shaded` just like OkHttp/Okio is today. With the Vert.x 5 adapter (available since Fabric8 7.6), Netty 4.2 is the upstream-tested pairing and aligns with Flink's own netty-bom (currently 4.2.15.Final). I tried this locally, and the full flink-kubernetes test suite passes with the shaded Vert.x adapter. We could alternatively also pin the exact Netty version Vert.x would use. The only downside I see would be the increased size of the distribution and the burden of maintaining the NOTICE files. In my tests the shaded JAR grew from 17.1 MB to 25.1 MB, with 24 new NOTICE entries (17 of them being Netty). Also, since Vert.x is the default HTTP client of Fabric8, it's also the most tested and used one, thus probably the most stable. Overall, I think using the Vert.x HTTP client could be a viable alternative. Best regards, Mate On Mon, Aug 24, 2026 at 5:24 AM Zhe Wang <[email protected]> wrote: > Hi Martijn, > > Thanks for writing this FLIP. The direction makes sense to me, especially > keeping EOL OkHttp out of the shared/core classpath. > > One point I think would be useful to make explicit is the boundary of the > Maven enforcer rules. Since the FLIP allows maintained OkHttp in isolated > plugin classloaders or standalone connector uber-jars, would the > implementation use an explicit module allow-list for those exceptions? That > may make the rule easier to maintain and avoid accidental regressions in > `flink-dist`. > > It would also be helpful if the enforcer failure message points > contributors to the intended alternatives, e.g. use the JDK HTTP client for > core/shared classpath code, or keep a maintained OkHttp dependency isolated > in a plugin/uber-jar when it is genuinely required. > > For the compatibility section, I also think the Java 11.0.19 floor is worth > calling out clearly in release notes, since the behavioral change is > internal but Kubernetes HA users running older Java 11 updates may > otherwise miss the WebSocket query-encoding limitation. > > Best regards, > Zhe Wang > > > Robert Metzger <[email protected]> 于2026年8月19日周三 16:45写道： > > > Looks like a good security hygiene improvement to me +1 > > > > On Wed, Aug 19, 2026 at 10:00 AM Martijn Visser < > [email protected]> > > wrote: > > > > > Hi all, > > > > > > I'd like to start a discussion on FLIP-607, which proposes migrating > > > Flink off the end-of-life OkHttp 3.x line and keeping OkHttp off the > > > core classpath [1] > > > > > > Motivation, in short: > > > > > > - Flink is pinned on OkHttp 3.14.9. It bundles okio 1.17.2, which > > > carries CVE-2023-3635 and flags on every scanner/SBOM. > > > - The pin blocks dependency modernization: the Fabric8 Kubernetes > > > client can't advance past 7.5, because from Fabric8 7.6.0 the OkHttp > > > adapter is compiled against the OkHttp 5 API. So flink-kubernetes is > > > stuck on Fabric8 7.3.1. > > > > > > Proposal, in short: > > > > > > - Switch flink-kubernetes from kubernetes-httpclient-okhttp to > > > kubernetes-httpclient-jdk (the built-in java.net.http client) > > > - Add Maven enforcer rules that forbid OkHttp on the core / flink-dist > > > classpath and ban EOL OkHttp 3.x globally, while allowing isolated > > > plugin/uber-jars to keep a maintained OkHttp where genuinely needed. > > > > > > One point worth flagging up front for reviewers: the JDK HttpClient > > > has a documented limitation where WebSocket requests, which is > > > explained in more detail in the FLIP. That's why the FLIP proposes a > > > minimum Java 11.0.19. > > > > > > Looking forward to your feedback. > > > > > > Thanks, > > > > > > Martijn > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/spaces/FLINK/pages/449282641/FLIP-607+Migrate+Flink+off+end-of-life+OkHttp+keep+it+off+the+core+classpath > > > > > >
