public Class HttpClientTransportDynamic

A HttpClientTransport that can dynamically switch among different application protocols.

Applications create HttpClientTransportDynamic instances specifying all the application protocols it supports, in order of preference. The typical case is when the server supports both HTTP/1.1 and HTTP/2, but the client does not know that. In this case, the application will create a HttpClientTransportDynamic in this way:

ClientConnector clientConnector = new ClientConnector();
// Configure the clientConnector.

// Prepare the application protocols.
ClientConnectionFactory.Info h1 = HttpClientConnectionFactory.HTTP11;
HTTP2Client http2Client = new HTTP2Client(clientConnector);
ClientConnectionFactory.Info h2 = new ClientConnectionFactoryOverHTTP2.HTTP2(http2Client);

// Create the HttpClientTransportDynamic, preferring h2 over h1.
HttpClientTransport transport = new HttpClientTransportDynamic(clientConnector, h2, h1);

// Create the HttpClient.
client = new HttpClient(transport);

Note how in the code above the HttpClientTransportDynamic has been created with the application protocols h2 and h1, without the need to specify TLS (which is implied by the request scheme) or ALPN (which is implied by HTTP/2 over TLS).

When a request is first sent, (scheme, host, port) are not enough to identify the destination because the same origin may speak different protocols. For example, the Jetty server supports speaking clear-text http/1.1 and h2c on the same port. Imagine a client sending a h2c request to that port; this will create a destination and connections that speak h2c; it won't be possible to use the connections from that destination to send http/1.1 requests. Therefore a destination is identified by a org.eclipse.jetty.client.Origin and applications can customize the creation of the origin (for example depending on request protocol version, or request headers, or request attributes, or even request path) by overriding HttpClientTransport#newOrigin(Request).