QUIC specifies max_idle_timeout as a QUIC transport parameter which is optionally sent by each endpoint (client and server) during connection establishment. This is the idle timeout value in seconds for the QUIC connection. If sent by either endpoint then the minimum of these 2 values is considered to be the effective idle timeout for that connection, which is then expected to be honoured by each endpoint.

QUIC further specifies the expectations of a idle timed out connection https://www.rfc-editor.org/rfc/rfc9000#section-10.1. Essentially, upon idle timeout, each endpoint is expected/allowed to completely discard the connection state (and thus no longer recongnize that connection), without sending any connection close frames to the peer.

HTTP/3 is an application protocol built on top of QUIC. In the JDK's implementation of the java.net.http.HttpClient, the HttpClient implementation maintains an internal connection pool for the HTTP/3 connection. The HttpClient allows applications to configure a timeout (for example, through the use of "jdk.httpclient.keepalive.timeout.h3" property) for how long a HTTP/3 connection can stay in pool without sending requests or receiving response. This timeout value is independent of the QUIC connection timeout.

If the HTTP/3 connection idle timeout value is higher than the effective negotiated max_idle_timeout for the QUIC connection, then it can so happen that the underlying QUIC connection can get terminated by either the local (client) or by the remote (server) peer, when the HTTP/3 connection is idle in the HttpClient's pool.

The independent timeout value on HTTP/3 connections is intentional and allows applications to decide how long they want the connection to be around even if idle. The QUIC implementation in the JDK should accomodate the (HTTP/3) application layer idle timeout configuration by not terminating the QUIC connection when there is absence of UDP traffic on that connection for larger durations than the negotitated max_idle_timeout value. Very specifically, if the HTTP/3 connection is in pool and there are no request/responses that are currently in progress for that connection and if the HTTP/3 connection idle timeout exceeds the QUIC connection idle timeout, then the JDK implementation of QUIC should periodically generate traffic over the UDP connection to keep the connection active and thus prevent the idle termination of the connection. In fact, the QUIC RFC allows for this https://www.rfc-editor.org/rfc/rfc9000#section-10.1 :

> An implementation of QUIC might provide applications with an option to defer an idle timeout. This facility could be used when the application wishes to avoid losing state that has been associated with an open connection but does not expect to exchange application data for some time. With this option, an endpoint could send a PING frame (Section 19.2) periodically, which will cause the peer to restart its idle timeout period. Sending a packet containing a PING frame restarts the idle timeout for this endpoint also if this is the first ack-eliciting packet sent since receiving a packet. Sending a PING frame causes the peer to respond with an acknowledgment, which also restarts the idle timeout for the endpoint. Application protocols that use QUIC SHOULD provide guidance on when deferring an idle timeout is appropriate. Unnecessary sending of PING frames could have a detrimental effect on performance.