[
https://issues.apache.org/jira/browse/HTTPCORE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18054686#comment-18054686
]
Ryan Schmitt commented on HTTPCORE-793:
---------------------------------------
[JEP 517: HTTP/3 for the HTTP Client API|https://openjdk.org/jeps/517]
specifically does _not_ add a QUIC API to Java. This is an ominous detail. I
would speculate that there are a few reasons for this:
# The QUIC ecosystem is still unstable, and the stewards of Java don't want to
add any APIs that they don't feel comfortable committing to for the next fifty
years
# QUIC probably invalidates a number of assumptions that are encoded in Java's
fundamental networking APIs: streams are not connections, the underlying socket
is UDP and not TCP, TLS is tightly coupled to the transport, connection
migration means the {{InetSocketAddress}} is mutable
>From our perspective, there are a few more points to consider:
# Every dependency is a liability, and any dependency we take to implement QUIC
is likely to be less stable than HttpComponents itself
# Most QUIC implementations are non-Java and would have to be called over JNI,
which is [going to be restricted|https://openjdk.org/jeps/472] in future
versions of Java due to the platform integrity strategy
# HTTP/3 version negotiation is more complicated than ALPN and more resembles
Happy Eyeballs (i.e. dynamic protocol family selection: IPv6 vs IPv4)
# The synchronous client is tightly coupled to the legacy {{java.net.Socket}}
(TCP) API and its corresponding assumptions ({{InetSocketAddress}}); it was
tricky enough to add Unix domain socket support
I think we should shoot for "last-mover advantage" here. We'll let the
ecosystem stabilize and mature and periodically reassess how much demand there
is for HTTP/3 versus how much work it would be to implement it. I suspect that
doing it properly would require us to put out version 6, and I'm in no hurry to
do that. Also, I think that HTTP/2 and HTTP/3 are fundamentally for web
browsers, and there are no web browsers written in Java; the client's main use
case is basically RPC, which is mostly still done over HTTP/1.1.
> Support HTTP/3
> --------------
>
> Key: HTTPCORE-793
> URL: https://issues.apache.org/jira/browse/HTTPCORE-793
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Reporter: Konrad Windszus
> Priority: Major
>
> HTTP/3 is specified in [https://datatracker.ietf.org/doc/html/rfc9114.] It
> relies on UDP/Quic (the latter not yet natively supported by Java so probably
> requiring a 3rd party library).
> HTTP/3 is meanwhile supported by [Jetty HTTP
> Client|https://jetty.org/docs/jetty/12.1/programming-guide/client/http.html#transport-http3]
> and [JDK HTTP Client|https://inside.java/2025/10/22/http3-support/]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
